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FOREWORD 


This  publication,  '*60SIP  Conformance  and  Interoperation  Testing 
and  Registration"  is  expected  to  be  published  as  a guideline  in  the 
Federal  Information  Processing  Standard  series  later  in  1991.  The 
provisions  of  GOSIP  Version  1.0  (FIPS  146)  became  mandatory 
requirements  for  acquisition  of  new  computer  networking  products 
and  services  as  of  August  15,  1990.  This  document  contains 
guidelines  for  agencies  wishing  to  specify  testing  requirements  for 
acquisitions  involving  GOSIP  implementations.  Any  agency 
referencing  this  report  in  an  acquisition  action  is  advised  to  make 
these  testing  provisions  an  agency  requirement. 

In  parallel  with  this  report,  NIST  is  establishing  and  operating 
the  Registration  procedures  described  herein,  together  with  the 
associated  Means  of  Testing  assessment  and  GOSIP  Conformance  Test 
Laboratory  Accreditation. 


NIST  Computer  Systems  Laboratory 
March,  1991 
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OVERVIEW 


The  development  of  Federal  Information  Processing  Standard  (FIPS) 
146  which  specifies  the  Government  Open  Systems  Interconnection 
Profile  (GOSIP)  [NIST  1] , resulted  in  the  need  to  establish  policy 
and  procedures  aimed  at  ensuring  that  Federally  procured  data 
communications  products  adhere  to  the  technical  documents 
referenced  by  GOSIP  and  that  they  interoperate.  The  goal  of  this 
report  is  to  aid  a Federal  Acquisition  Authority  in  procurement  of 
GOSIP  products  by  employing  publicly  accessible  registers 
verifying  supplier  claims  of  conformance  and  documenting  instances 
of  interoperability  of  GOSIP  conformant  products. 

To  achieve  this  goal,  this  report  references  other  publicly 
accessible  registers,  other  publications,  and  works  conducted 
under  the  auspices  of: 

the  National  Voluntary  Laboratory  Accreditation  Program, 
the  OSI  Implementors*  Workshop, 

the  Computer  Systems  Laboratory  or  its  designated  Agent,  and 
the  International  Organization  for  Standardization  (ISO) . 

This  report  describes  the  use  of  ISO's  OSI  Conformance  Testing 
Methodology  and  Framework  [ISO  1]  for  the  purposes  of  GOSIP 
testing. 

This  is  a multi-part  report  in  which  the  policy,  procedures  and 
testing  mechanisms  for  GOSIP  products  are  specified  in  Part  I; 
Part  II  describes  specific  testing  criteria  for  GOSIP  Version  1.0 
protocols.  The  framework  provided  herein  may  be  extended  as 
subsequent  versions  of  GOSIP  are  issued. 

This  report  identifies  requirements  for  conformance  testing  and 
interoperability  testing  of  GOSIP  protocols  (and  protocol  stacks) . 
The  framework  includes  comprehensive  GOSIP  testing  through  use  of 
a test  laboratory  accreditation  program.  In  order  to  effectively 
realize  the  goal  of  GOSIP,  products  which  interoperate  and  are 
available  off-the-shelf  for  Government  procurement,  issues 
identified  below  are  addressed  by  the  report. 

Conformance  Testing:  Policy,  procedures  and  criteria  are 
identified.  Conformance  testing  shall  be  conducted  by 
accredited  test  laboratories  using  assessed  and  registered 
Means  of  Testing.  Registered  results  of  conformance  testing 
will  be  published  periodically  for  purposes  of  Federal 
procurement.  Mutual  recognition  of  other  conformance  testing 
authorities'  results  will  be  considered  using  these  criteria 
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as  a basis. 


Interoperability  Testing;  For  suppliers  claiming  GOSIP 
conformance,  interoperability  testing  against  a Registered 
GOSIP  Reference  Entity  is  advised  for  GOSIP  application  and 
relay  stacks.  Criteria  and  procedures  are  identified  to 
select  and  register  one  reference  entity  for  each  GOSIP 
application  stack.  NIST  will  solicit,  select  and  register 
GOSIP  Reference  Entities  meeting  criteria  specified;  this 
does  not  preclude  NIST*s  providing  reference  entities  which 
meet  the  same  criteria.  This  interoperability  testing  is 
advised  if  and  only  if  GOSIP  Reference  Entities  are  selected 
and  registered.  NIST  (or  its  agent)  conducts 

interoperability  testing  between  vendors  products  and  GOSIP 
Reference  Entities  using  NIST  registered  Interoperability 
Test  Suites.  Supplier-to-supplier  interoperability  testing 
of  GOSIP  products  may  be  conducted  resulting  in  addition  to 
a NIST  approved  register. 

Any  forum  in  which  Interoperability  testing  is  conducted 
which  uses  registered  Interoperability  Test  Suites  and  which 
meets  the  criteria  specified  herein  may  be  approved  as  a 
registered  Interoperability  Testing  Service. 

Laboratory  Accreditation;  Policies  and  procedures  are 
published  under  the  auspices  of  the  National  Voluntary 
Laboratory  Accreditation  Program  (NVLAP)  and  include: 
policy,  procedures  and  criteria  to  determine  that  candidate 
test  laboratories  are  qualified  to  conduct  GOSIP  product 
testing;  procedures  and  criteria  to  determine  that  registered 
test  methods  are  employed  by  candidate  test  laboratories. 

Abstract  Test  Suites;  Criteria  identified  for  test  suite 
coverage  in  this  report  will  be  applied  to  identify  or 
develop,  amend  as  necessary,  and  maintain  a set  of  Abstract 
Test  Suites  for  GOSIP.  Abstract  test  suites  registered  by 
the  NIST  will  be  used  as  the  standard  reference  for  the 
assessment  of  Means  of  Testing  in  this  report. 

Public  Registers;  Registers  shall  be  maintained  and 
published  periodically  for  the  following: 

1)  Accredited  test  laboratories; 

2)  Qualified  Means  of  Testing; 

3)  Abstract  test  suites  for  GOSIP; 

4)  NIST  supplied  reference  entities; 

5)  Successfully  conformance  tested  GOSIP  products; 
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6)  Successfully  interoperability  tested  GOSIP  products; 

7)  GOSIP  Interoperability  Test  Suites; 

8)  Interoperability  Testing  and  Registration  Services. 

This  report  does  not  distinguish  between  a conformance  testing 
laboratory  which  is  first  party  (self-testing)  or  third  party 
(independent  of  product  supplier) , however  each  Acquisition 
Authority  may  choose  to  require  third  party  testing,  at  its  own 
option. 


The  relationships  between  FIPS  146  GOSIP  and  the  "GOSIP 

Conformance  and  Interoperation  Testing  and  Registration"  report 

are  as  follows: 

1)  GOSIP  shall  be  used  by  Federal  Government  Agencies  when 
acquiring  computer  network  products  and  services  and 
communications  systems  or  services  that  provide  equivalent 
functionality  to  the  protocols  defined  in  the  GOSIP  FIPS  146 
and  referenced  standards. 

2)  If  a supplier  claims  GOSIP  compliance  or  conformance  for  a 
product  then  the  Agency  is  advised  to  require  that  product  to 
be  tested  in  accordance  with  the  criteria  specified  in  the 
GOSIP  Conformance  and  Interoperation  Testing  and  Registration 
report.  If  the  product  includes  a multi-layered  GOSIP 
profile  then  all  protocols  for  which  GOSIP  compliance  or 
conformance  is  claimed  should  be  tested  in  accordance  with 
these  criteria. 

3)  Federal  Government  Agencies  requiring  verification  of 
suppliers  claims  of  GOSIP  conformance  should  consult  the 
Register  of  Conformance  Tested  GOSIP  Products. 

4)  Federal  Government  Agencies  wishing  to  procure  OSI  products 
that  are  not  on  the  register  are  advised  to  arrange  that  the 
product  qualify  for  registration  prior  to  final  acceptance. 

5)  Federal  Government  Agencies  requiring  an  increased  confidence 
that  GOSIP  conformant  products  will  interoperate  should 
consult  the  register  of  successfully  interoperability  tested 
GOSIP  products,  if  a NIST  supplied  reference  implementation 
is  registered  for  the  protocol  stack  in  question. 

6)  Federal  Government  Agencies  should  consult  the  data  supplied 
by  a service  on  the  register  of  Interoperability  Test  and 
Registration  Services  under  any  of  these  conditions: 
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a)  The  agency  requires  increased  confidence  that  a specific 
GOSIP  conformant  product  is  interoperable  and  no  NIST 
supplied  reference  implementation  is  registered  for  the 
protocol  stack. 

b)  The  agency  requires  that  multiple  instances  of  successful 
interoperation  are  documented  for  a specific  GOSIP  conformant 
product . 

c)  The  agency  requires  that  an  instance  of  successful 
interoperation  is  documented  for  one  or  more  specific  pairs 
of  GOSIP  conformant  products. 


vii 


60SIP  CONFORMANCE  AND  INTEROPERATION  TESTING  AND  REGISTRATION 


PART  I:  GENERAL  REQUIREMENTS  FOR  TESTING  GOSIP 


I 


\ 

I 

.«! 


1. 


INTRODUCTION 


Acceptance  of  vendor  products  for  use  within  Government  operations 
is  the  responsibility  of  the  Acquisition  Authority.  Normally,  an 
Acquisition  Authority  develops  an  acceptance  test  plan  to  evaluate 
the  functional  and  performance  characteristics  of  proposed 
products  against  requirements  specified  within  a request  for 
proposal  (RFP) . When  an  Acquisition  Authority  introduces  a 
requirement  for  standards  compliance  within  an  RFP,  a new  testing 
issue  is  created  - determining  compliance  of  proposed  products 
with  the  standard.  When  a data  communication's  standard,  such  as 
the  Government  Open  Systems  Interconnection  Profile  (GOSIP)  [NIST 
1]  is  cited,  an  additional  testing  issue  arises  - determining 
interoperability  between  proposed  products  and  existing  products 
that  are  known  to  comply  with  the  GOSIP. 

The  GOSIP  Conformance  and  Interoperation  Testing  and  Registration 

is  intended  to  provide  the  Acquisition  Authority  with  as  much 
assistance  as  possible  to  determine  compliance  to  GOSIP  and  to 
demonstrate  interoperability  between  vendor  products  purporting  to 
comply  with  GOSIP.  The  Acquisition  Authority  should  reserve  the 
right  to  test  proposed  products  against  more  stringent  criteria 
should  the  need  exist  and  should  the  cost  be  justified.  In  such 
cases,  the  following  GOSIP  test  policy  will  provide  a significant 
foundation. 

1 • 1 Background 

The  National  Institute  of  Standards  and  Technology  (NIST) , 
Computer  Systems  Laboratory  (CSL)  is  responsible  for  developing 
U.S.  Government-wide  Standards  for  data  communications  networks 
and  related  telecommunication  systems.  The  authority  for  this 
responsibility  is  assigned  under  the  Federal  Property  and 
Administrative  Services  Act  of  1949,  as  amended  by  Public  Law  100- 
235. 

NIST  CSL  develops  standards,  provides  technical  assistance,  and 
carries  out  research  to  advance  the  effective  use  of  computers  by 
government  and  industry.  NIST  CSL  works  through  voluntary 
industry  standards  organizations  to  develop  standards  that  will 
meet  the  needs  of  government  users.  These  standards  are  issued  as 
Federal  Information  Processing  Standards  (FIPS)  and  provide  the 
foundation  for  compatibility  and,  where  necessary, 
interoperability  between  government  systems  implementing  these 
standards.  FIPS  also  serve  as  the  basis  for  Government 
acquisition  of  commercial  off-the-shelf  products  and  services  from 
competitive  sources. 
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The  pace  of  standards  development  for  data  communications  networks 
and  telecommunications  has  intensified  in  recent  years,  stimulated 
by  user  needs  for  interconnectivity  of  hardware,  software,  and 
network  systems.  These  standards  are  increasingly  complex — -often 
describing  functional  requirements  and  allowing  for  numerous 
options  in  implementation. 

To  achieve  interoperability  and  effective  use  of  information 
systems,  users  need  off-the-shelf  products  that  work  together  and 
conform  to  these  emerging  standards.  Where  products  are  expected 
to  support  complex  standards  specifications,  conformance  testing 
may  be  required  to  reduce  risks  and  raise  consumer  confidence  in 
information  system  products. 

NIST  CSL  is  responsible  for  organizing,  managing,  directing  and 
administering  the  FIPS  program.  Among  the  responsibilities 
assigned  under  the  FIPS  program  is  the  task  of  insuring  that,  for 
products  to  be  acquired  by  the  Federal  Government,  a mechanism  is 
available  for  determining  that  these  products  conform  to  the  FIPS. 
In  carrying  out  this  task,  the  NIST  CSL  develops  and  maintains 
conformance  testing  programs  for  the  FIPS.  These  programs  require 
adequate  test  methods  and  procedures,  suitable  candidate  test 
laboratories  for  accreditation,  and  a formal  acknowledgement  of 
product  testing  for  compliance  or  noncompliance  to  a FIPS. 

1.2  Purpose 

This  document  is  intended  to  inform  Government  agencies,  industry, 
standards  development  bodies,  and  other  interested  organizations 
of  the  NIST  CSL  policy  with  regard  to  conformance  testing  and 
interoperability  testing  of  GOSIP  products  which  are  conformant 
and  interoperable. 

The  purpose  of  this  report  is  to  provide  the  framework  for  uniform 
Government-wide  procurement  of  GOSIP  conformant  products. 

The  objectives  of  GOSIP  Conformance  and  Interoperation  Testing  and 
Registration  are: 

To  reduce  the  overall  information  systems  costs  by  making  it 
easier  and  less  expensive  to  maintain  information  technology 
applications  and  to  transfer  these  applications  among 
different  information  systems,  including  replacement  systems; 

To  protect  the  technical  assets  and  staff  time  of  the  Federal 
Government  by  insuring  to  the  extent  possible  that  products 
(off-the-shelf  or  government  developed)  brought  into  the 
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Federal  inventory  comply  with  Government  approved  FIPS; 

- To  identify  test  methods  and  competent  test  laboratories  for 
assisting  Government  agencies  in  the  procurement  of  industry 
supplied  GOSIP  products; 

To  increase  the  likelihood  of  interoperability  of  GOSIP 
conformant  products. 

Further  detailed  solutions  to  the  guidelines  in  this  report  are 
given  in  companion  handbooks: 

The  "NVLAP  Program  Handbook:  Operational  Requirements  of  the 
Laboratory  Accreditation  Program  for  GOSIP  Conformance  Testing" 
[NIST  6]  provides  the  administrative  procedures  for  NVLAP 
accreditation . 

The  "Government  Open  Systems  Interconnection  Profile  (GOSIP)  Means 
of  Testing  Assessment  Handbook"  [NIST  7]  explains  the  technical 
and  administrative  procedures  for  the  assessment  of  MOTs  for  GOSIP 
protocols. 

The  "Government  Open  Systems  Interconnection  Profile  (GOSIP) 
Registration  Criteria"  handbook  [NIST  8]  identifies  the  registers 
of  tests,  test  systems,  laboratories  and  products  and  describes 
the  administrative  criteria  for  registration. 


1.3  Scope 

This  report  provides  detailed  advisory  provisions  with  respect  to 
conformance  and  interoperability  testing  given  in  FIPS  146 
Government  Open  Systems  Interconnection  Profile  (GOSIP)  Version 
1.0.  This  report  defines  policy  and  procedures  related  to 
conformance  testing  and  interoperability  testing  for  GOSIP. 
Other  types  of  testing  such  as  performance,  acceptance,  and 
quality  testing,  are  not  addressed. 

In  determining  testing  requirements  for  GOSIP,  a number  of  areas 
are  considered:  Government  testing  needs,  test  method  technology, 
standard  specifications,  alternative  testing  sources  (third-party 
testing.  Government  testing,  self-testing,  etc.),  and  existing 
accreditation  and  certification  systems. 

The  policy  and  procedures  for  conformance  testing  and  for 
interoperability  testing  defined  herein  apply  whenever  GOSIP 
standards  are  required  to  support  Government  objectives  for 
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information  systems. 

The  report  is  addressed  to: 

1)  Agencies  of  the  Federal  Government  intending  to  procure  OS I 
products ; 

2)  Suppliers  of  OSI  products  wishing  to  market  to  the  Federal 
Government ; 

3)  Suppliers  of  OSI  test  services  seeking  accreditation  as  a 
test  laboratory; 

4)  Developers  of  the  means  of  testing  OSI  products  wishing  to 
supply  to  accredited  laboratories. 

5)  Suppliers  of  OSI  interoperability  testing  and  registration 
services  seeking  recognition  by  the  Federal  Government. 

The  program  of  registration  will  be  administered  by  the  NIST  CSL, 

or  its  appointed  agent,  who  will  have  authority  delegated  by  the 

Director  of  CSL.  In  the  text  that  follows  the  acronym  "NIST  CSL*" 

is  used  to  mean  "NIST  CSL  or  its  agent" . 


1.4  Overview  of  Testing 

This  report  is  concerned  with  conformance  and  interoperability 
testing  from  the  point  of  view  of  both  their  conduct  and  the 
evaluation  of  their  methods.  To  eliminate  confusion  over  which 
role  is  being  addressed  this  report  draws  the  distinction  between 
the  terms  assessment  and  accreditation  on  the  one  hand,  and 
testing  on  the  other. 

Testing  means  using  tools,  facilities  and  procedures  to  establish 
that  implementations  of  GOSIP  related  products  are  conformant 
and/or  interoperable. 

Assessment  is  the  process  of  determining  that  testing  tools  are 
fit  for  their  declared  purpose. 

Accreditation  is  the  administrative  act  of  recognizing  that 

1)  a test  laboratory  is  qualified  to  conduct  protocol  testing 
after  having  met  specific  technical  and  organizational  criteria, 
and 

2)  the  means  of  testing  employed  by  a test  laboratory  meets 
specific  technical  criteria. 
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Registration  is  the  administrative  act  of  recognizing  that  the 
tested  products  meet  specified  criteria  by  registering  the  results 
after  successful  testing  has  been  conducted. 

Within  the  International  Organization  for  Standardization  (ISO) 
conformance  testing  methodology  has  developed  and  is  the  subject 
of  a separate  standard  (IS  9646  OSI  Conformance  Testing 
Methodology  and  Framework)  [ISO  1]  . Its  purpose  is  to  define 
standardized  methods  which  may  be  used  for  conformance  testing  and 
to  define  relationships  between:  1)  parties  supplying  the  means 
of  testing  OSI  protocols  and  test  laboratories,  and  2)  test 
laboratories  and  their  clients,  and  the  information  exchanged 
between  them.  Conformance  testing  concentrates  on  determining 
whether  an  implementation  of  a protocol  conforms  to  both  static 
and  dynamic  requirements  specified  in  a protocol  standard. 

Current  conformance  testing  technology  provides  for  tools  which 
separate  the  testing  concerns  of  any  7-layer  OSI  stack  into  three 
functional  groups: 

- Upper  Layers:  Session,  Presentation,  Application 

- Intermediate  Layers:  Network,  Transport 

- Lower  Layers:  Physical,  Link 

Higher  layer  protocols  are  tested,  and  operated,  over  a stack  of 
supporting  protocols.  IS  9646  prescribes  testing  of  the  lower 
layer  protocols  prior  to  testing  the  protocols  which  they  support. 
One  reason  for  this  arrangement  is  that  direct  access  to  a layer 
service  affords  the  greatest  possible  capability  of  controlling 
and  observing  events  within  that  layer.  Another  reason  is  that 
the  development  of  the  means  of  testing  followed  the  development 
of  protocol  stack  implementations,  and  the  means  of  testing  for 
lower  layer  protocols  were  available  earliest.  An  advantage 
afforded  by  this  approach  is  that  the  Protocol  Conformance  Test 
Report  (PCTR)  can  be  used  in  support  of  incremental  testing, 
specifically  so  that  full  regression  testing  is  not  needed  in 
testing  a larger  stack  which  builds  on  the  already  tested 
functional ity . 

Full-stack  testing  is  also  an  alternative,  although  no  7-layer 
means  of  testing  is  currently  in  existence.  Full  stack  methods 
require  that  each  protocol  in  the  stack  be  tested  by  embedded 
methods  (except  the  Application  protocols  which  are  tested  by 
single-layer  methods) . This  procedure  is  repeated  for  every  new 
Application  stack,  since  each  new  service  user  may  exercise  paths 
within  a lower  layer  protocol  which  are  not  explored  by  a 
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different  service  user  in  another  full  stack. 


More  recently  interoperability  testing  has  been  identified  as  a 
necessary  step  in  demonstrating  interworking  of  OSI 
implementations.  Whereas  the  failures  in  conformance  testing  are 
likely  to  be  software  errors,  interworking  problems  seem  more 
likely  to  include  problems  of  parameter  range  selection,  plus 
attempts  to  use  incompatible  stacks,  attempts  to  use  optional 
functions  not  implemented,  and  failures  to  implement  mandatory 
functions.  Consequently,  interoperability  assurance  will  be 
developed  iteratively  by  testing  and  tuning.  The  methodology  and 
test  suites  employed  are  subject  to  the  criteria  given  in  clause 
6.3.  Since  it  is  necessary  to  assess  the  interoperability  of 
systems,  this  report  identifies  two  steps:  testing  against  a 
government  supplied  reference  entity,  and  multi-vendor  bilateral 
interoperability  testing. 

1.5  Organization  of  this  Report 

This  report  provides  the  overall  procedures  for  the  operation  of 
the  GOSIP  testing  and  registration  program,  and  specific  technical 
criteria  pertaining  to  GOSIP  protocols  and  profiles.  Consequently 
this  report  is  organized  into  separate  but  related  parts:  Part  I 
provides  the  overall  policy  and  operational  criteria;  Part  II 
provides  technical  criteria  for  GOSIP  Version  1.0;  future  versions 
of  GOSIP  will  be  the  subject  of  further  technical  increments  to 
this  report  or  the  associated  FIPS. 


Ic6  Definitions 

Abstract  Test  Case:  A complete  and  independent  specification  of 
the  actions  required  to  achieve  a specific  test  purpose  (or  a 
specified  combination  of  test  purposes) , defined  at  the  level  of 
abstraction  of  a particular  abstract  test  method.  It  may  include 
a preamble  and  postamble  to  ensure  starting  and  ending  in  a stable 
state  (i.e.  an  identifiable  stable  state  of  the  System  Under 
Test  which  can  be  easily  reached  and  maintained,  such  as  the 
•idle*  state  or  the  *data  transfer*  state).  This  specification 
may  involve  one  or  more  consecutive  or  concurrent  connections. 

Abstract  Test  Method:  The  description  of  how  an  Implementation 
Under  Test  is  to  be  tested,  given  at  an  appropriate  level  of 
abstraction  to  make  the  description  independent  of  any  particular 
implementation  of  testing  tools,  but  with  enough  detail  to  enable 
tests  to  be  specified  for  this  test  method. 
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Acceptance  Testing:  Formal  testing  conducted  to  determine  whether 
or  not  a system  satisfies  its  acceptance  criteria  and  to  enable 
the  customer  to  determine  whether  to  accept  the  system.  Formal 
testing  may  include  the  planning  and  execution  of  several  kinds  of 
tests  (e.  g. , functional,  volume,  performance  tests)  to 
demonstrate  that  the  implementation  satisfies  the  customer 
requirements . 

Accreditation  Body:  An  impartial  body,  governmental  or 
nongovernmental,  possessing  the  necessary  competence  and 
reliability  to  operate  or  accredit  operation  of  an  accreditation 
system,  and  in  which  the  interests  of  all  parties  concerned  with 
the  function  of  the  system  are  represented. 

Basic  Interconnection  Tests:  Limited  tests  of  an  Implementation 
Under  Test  (lUT)  to  determine  whether  or  not  there  is  sufficient 
conformance  to  the  relevant  protocol (s)  for  interconnection  to  be 
possible,  without  trying  to  perform  thorough  testing. 

Behavior  Tests:  Tests  to  determine  the  extent  to  which  the 
dynamic  conformance  requirements  are  met  by  the  lUT. 

Capability  Tests:  Tests  to  determine  the  capabilities  of  an  lUT. 
(Note,  this  involves  checking  all  mandatory  capabilities  and  those 
optional  ones  that  are  stated  in  the  Protocol  Implementation 
Conformance  Statement  (PICS)  as  supported,  but  not  checking  those 
optional  ones  which  are  stated  in  the  PICS  as  not  supported  by  the 
lUT. ) 

Conformance:  In  the  context  of  OSI  a real  system  is  said  to 
exhibit  conformance  if  it  complies  with  the  requirements  of 
applicable  OSI  standards  in  its  communication  with  other  real 
systems . 

Conformance  Testing:  Testing  the  extent  to  which  an  lUT  is  a 
conforming  implementation. 

Coordinated  Test  Method:  An  external  test  method  for  which  a 
standardized  test  management  protocol  is  defined  as  the  test 
coordination  procedures,  enabling  the  control  and  observation  to 
be  specified  solely  in  terms  of  the  lower  tester  activity, 
including  the  control  and  observation  of  test  management  PDUs. 

Distributed  Test  Method:  An  external  test  method  in  which  there 
is  a PCO  at  the  layer  boundary  at  the  top  of  the  lUT. 

Dyneunic  Conformance  Requirements:  All  those  requirements  and 
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options  which  determine  what  observable  behavior  is  permitted  by 
the  relevant  OSI  standards  in  instances  of  communication. 

Dyneuaic  Interopercdsility  Requirements:  All  those  requirements  and 
options  which  determine  what  observable  behavior  is  permitted 
between  peer  open  systems  by  compatible  standardized  profiles  of 
OSI  standards,  in  instances  of  communication. 

Embedded  Testing:  Testing  the  behavior  of  a single  layer  within 
a multi-layer  lUT  without  accessing  the  layer  boundaries  for  that 
layer  within  the  lUT.  (This  is  contrasted  with  ’exposed*  testing 
in  which  the  N-service  PCO  of  the  lUT  is  accessible  for  testing.) 

Equivalent  Configuration:  Any  configuration  for  which  conformance 
is  achievable  using  the  same  registered  test  method  version  used 
in  conformance  testing  of  an  implementation  under  test. 

60SIP  Product:  A product  which  implements  one  or  more  of  the  data 
communications  protocols  identified  in  GOSIP  and  meets  the 
requirements  specified  herein. 

Implementation  Under  Test  (lUT)  : An  implementation  of  one  or  more 
OSI  protocols  in  an  adjacent  user/provider  relationship,  being 
that  part  of  a real  open  system  which  is  to  be  studied  by  testing. 

Interconnection:  Establishment  of  communication  between  peer 
protocol  entities  over  a physical  medium  or  an  OSI  layer  service. 

Interopercddility  Test:  An  informal  test  script  specified  in  terms 
of  abstract  services,  which  includes  protocol  exchange 
requirements,  designed  to  achieve  a specified  test  purpose. 

Interoperability  Testing:  Testing  pairs  of  compatible, 
conforming,  open  systems  to  demonstrate  provision  of  the 
application  service  by  each  peer. 

Means  of  Testing:  The  realization  of  an  abstract  test  method  as 
defined  in  the  OSI  Conformance  Testing  Methodology  and  Framework. 
This  realization  includes  the  test  system,  executable  test  suite, 
testing  support  tools  (hardware  and  software)  and  documentation 
(including  technical  test  procedures) . 

Multi-Layer  Testing:  Testing  the  behavior  of  a multi-layer  lUT  as 
a whole,  rather  than  testing  it  layer  by  layer  (in  contrast  to 
Single-Layer  Testing) . 

National  Voluntary  LadDoratory  Accreditation  Program  (NVLAP) : A 
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voluntary  system  for  accrediting  laboratories  found  competent  to 
perform  specific  testing  operations.  It  is  part  of  the  National 
Institute  of  Standards  and  Technology  Office  of  Associate  Director 
for  Industry  and  Standards.  NVLAP  does  not  confer  product  or  test 
data  certification. 

Out-of-band  Coordination:  A separate  communications  path  used  for 
test  coordination  procedures  which  may  be  realized  from  a lower- 
layer  service  or  alternative  physical  media. 

Product  Interoperaibility  Test  Report:  This  is  a document  written 
at  the  end  of  the  interoperability  testing  process,  giving  the 
details  of  the  testing  carried  out  for  a specific  interoperability 
test  suite. 

Proficiency  Testing:  Determination  of  laboratory  testing 
performance  by  means  of  comparison  of  tests  on  the  same  or  similar 
items  by  two  or  more  laboratories  in  accordance  with  predetermined 
conditions . 

Protocol  Conformance  Test  Report  (PCTR) : A document  written  at 
the  end  of  the  conformance  assessment  process,  giving  the  details 
of  the  testing  carried  out  for  a particular  protocol.  It  includes 
the  identification  of  the  abstract  test  cases  (if  these  exist)  for 
which  corresponding  executable  test  cases  were  run.  It  also 
includes  the  test  purpose (s)  and  verdict  for  each  test  case. 

Protocol  Implementation  Conformance  Statement  (PICS) : A statement 
made  by  the  supplier  of  an  OSI  implementation,  or  system,  stating 
which  capabilities  and  options  have  been  implemented,  for  a given 
OSI  protocol. 

Protocol  Implementation  extra  Information  for  Testing  (PIXIT) : 

A statement  made  by  a supplier  or  implementor  of  an  lUT  which 
contains  or  references  all  of  the  information  (in  addition  to  that 
given  in  the  PICS)  related  to  the  lUT  and  its  testing  environment, 
which  will  enable  the  test  laboratory  to  run  an  appropriate  test 
suite  against  the  lUT. 

Remote  Test  Method:  An  external  test  method  in  which  there  is 
neither  a PCO  above  the  lUT  nor  a standardized  test  management 
protocol ; some  requirements  for  test  coordination  procedures  may 
be  implied  or  informally  expressed  in  the  abstract  test  suite  but 
no  assumption  is  made  regarding  their  feasibility  or  realization. 

Single-Layer  Testing:  Testing  the  behavior  of  one  layer-protocol 
from  a multi-layer  lUT. 
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static  Conformance  Requirements:  Constraints  which  are  specified 
in  OSI  standards  to  facilitate  interworking  by  defining  the 
requirements  for  the  capabilities  of  an  implementation. 

Static  Interoperedsility  Requirements:  For  potentially 

interoperable  peers  these  include: 

- Compatible  static  conformance  requirements; 

- Both  systems  successfully  conformance  tested; 

“ Peers  are  configured  to  enable  interconnection. 

System  Conformance  Test  Report  (SCTR) : A document  written  at  the 
end  of  the  conformance  assessment  process,  giving  the  overall 
summary  of  the  conformance  of  the  system  to  the  set  of  protocols 
for  which  conformance  testing  was  carried  out. 

System  Under  Test  (SUT)  : The  real  open  system  in  which  the  lUT 
resides. 

Test  System  Environment  Specification:  This  is  a statement  made 
by  a supplier  or  an  implementor  of  an  OSI  product  which  contains 
or  references  all  of  the  information  (in  addition  to  that  given  in 
the  PICS)  related  to  the  implementation  and  its  environment,  which 
will  enable  the  test  parties  to  execute  an  appropriate  test  suite 
against  their  implementations. 

Verdict:  A statement  of  "Pass",  "Fail",  or  "Inconclusive", 

specified  in  the  abstract  test  suite  concerning  conformance  of  an 
lUT  with  respect  to  a test  case  that  has  been  executed. 

1.7  Abbreviations 

AARE  A_Associate_Response  Service  Primitive 

AARQ  A_Associate_Request  Service  Primitive 

ACSE  Association  Control  Service  Elements 

APDU  ACSE  Protocol  Data  Unit 

ASN.l  Abstract  Syntax  Notation  One 

CLNF  Connectionless  Network  Protocol 

CLNPDU  Connectionless  Network  Protocol  Data  Unit 

CLNS  Connectionless  Network  Service 

CONS  Connection  Oriented  Network  Service 

CP  Presentation  Connect  PPDU 

CPA  Presentation  Accept  PPDU 

CPR  Presentation  Reject  PPDU 

CR  Connect  Request  TPDU 

ES  End  System 
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FIPS  Federal  Information  Processing  Standard 

PPDU  File  Protocol  Data  Unit 

FTAM  File  Transfer  Access  and  Management 

60SIP  Government  Open  Systems  Interconnection  Profile 

HDLC  High-level  Data  Link  Control 

IPMS  Interpersonal  Messaging  Service 

IS  Intermediate  System  (or  International  Standard) 

LAPS  Link  Access  Procedure  B 

LLC  Logical  Link  Control 

MTA  Message  Transfer  Agent 

CSL  Computer  Systems  Laboratory 

NVLAP  National  Voluntary  Laboratory  Accreditation  Program 

OSI  Open  Systems  Interconnection 

PI  PI  Protocol  for  Message  Transfer  Agents 

P2  P2  Protocol  for  Interpersonal  Messaging  Services 

PCO  Point  of  Control  and  Observation 

PCTR  Protocol  Conformance  Test  Report 

PPDU  Presentation  Protocol  Data  Unit 

QOS  Quality  of  Service 

RTS  Reliable  Transfer  Service 

SCTR  System  Conformance  Test  Report 

TTP  Transport  Test  Platform 

TPO  Transport  Protocol  Class  0 

TP4  Transport  Protocol  Class  4 


1.8  References 

National  Institute  of  Standards  and  Technology  (NIST) 

1.  Government  Open  Systems  Interconnection  Profile  (GOSIP) , 
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Technical  Information  Service,  U.  S.  Department  of  Commerce, 
5285  Port  Royal  Road,  Springfield,  Virginia  22161. 

(This  document  in  turn  gives  complete  references  for  all  of 
the  base  standards  employed  by  this  FIPS.) 

2 . Stable  Implementation  Agreements  for  Open  Systems 

Interconnection  Protocols,  Version  No.  1,  December  1987,  NIST 
Special  Publication  500-150,  National  Technical  Information 
Service,  U.  S.  Department  of  Commerce,  5285  Port  Royal  Road, 
Springfield,  Virginia  22161. 

3.  GOSIP  Users  Guide,  NIST  Special  Publication  500-163, 

National  Technical  Information  Service,  U.  S.  Department  of 
Commerce,  5285  Port  Royal  Road,  Springfield,  Virginia  22161. 
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POSIX:  Portable  Operating  System  Interface  for  Computer 
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U.  S.  Department  of  Commerce,  National  Institute  of  Standards 
and  Technology,  March  1990,  National  Technical  Information 
Service,  U.  S.  Department  of  Commerce,  5285  Port  Royal  Road, 
Springfield,  Virginia  22161. 

5.  Computer  Protocols  Handbook  - Operational  and  Technical 
Requirements  of  the  Leiboratory  Accreditation  Prograua  for 
Computer  Network  Interface  Protocol  X.25,  National  Voluntary 
Laboratory  Accreditation  Program,  December  1988,  National 
Technical  Information  Service,  U.  S.  Department  of  Commerce, 
5285  Port  Royal  Road,  Springfield,  Virginia  22161. 

6.  NVLAP  Handbook:  Operational  Requirements  of  the  Laboratory 
Accreditation  Program  for  60SIP  Conformance  Testing,  National 
Voluntary  Laboratory  Accreditation  Program,  August  1990. 
National  Technical  Information  Service,  U.  S.  Department  of 
Commerce,  5285  Port  Royal  Road,  Springfield,  Virginia  22161. 

7.  Government  Open  Systems  Interconnection  Profile  (GOSIP)  Means 

of  Testing  Assessment  Handbook,  NCSL/SNA-90/3 , August  1990, 
National  Institute  of  Standards  and  Technology,  National 
Computer  Systems  Laboratory,  GOSIP  Testing  Program, 

Gaithersburg,  MD  20899. 

8.  Government  Open  Systems  Interconnection  Profile  (GOSIP) 
Registration  Criteria,  NCSL/SNA-90/4 , August  1990,  National 
Institute  of  Standards  and  Technology,  National  Computer 
Systems  Laboratory,  GOSIP  Testing  Program,  Gaithersburg,  MD, 
20899. 

9.  Staible  Implementation  Agreements  for  Open  Systems 

Interconnection  Protocols,  Version  No.  3,  December  1989,  NIST 
Special  Publication  500-177,  National  Technical  Information 
Service,  U.  S.  Department  of  Commerce,  5285  Port  Royal  Road, 
Springfield,  Virginia  22161. 

10.  Programming  Languages  and  Database  Language  SQL  VALIDATED 
PROCESSOR  LIST  Including  GOSIP  Conformance  Testing  Registers, 
NISTIR  4500,  Quarterly  Publication,  Ed.  Judy  B.  Kailey, 
National  Institute  of  Standards  and  Technology,  Computer 
Systems  Laboratory,  Software  Standards  Validation  Group, 
Ga ither sburg , MD , 20899. 
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International  Organization  for  Standardization  (ISO) 

ISO  documents  are  available  from:  American  National  Standards 

Institute,  1430  Broadway,  New  York,  NY  10018. 

1.  OSI  Conformance  Testing  Methodology  and  Fraunework,  Parts  1-5, 
ISO  DIS  9646. 

2 . General  Requirements  for  the  Technical  Competence  of  Testing 
L2d>oratories,  ISO/IEC  Guide  25,  1982. 

3.  Information  on  Manufacturer's  Declaration  of  Conformity  with 
Standards  or  other  Technical  Specification,  ISO/lEC  Guide  22, 
1982. 

4.  X.25  DTE  Conformance  Testing,  Revised  text  for  Data  Link 
Layer  Test  Suite,  DP8882-2,  ISO/IEC  JCT  1/SC  6/WG  1 N XXX. 

5.  X.25  DTE  Conformance  Testing,  Packet  Layer  Test  Suite,  DP 

8882-3,  ISO/IEC  JCT  1/SC  6/WG  2 N304. 

6.  Information  Processing  - Open  Systems  Interconnection  - 

Estelle  - A formal  description  technique  based  on  an  extended 
state  transition  model,  ISO  9074,  1988. 

7.  Information  Processing  Systems  - Open  Systems  Interconnection 
- LOTOS  - A formal  description  technique  based  on  the 
temporal  ordering  of  observational  behavior,  ISO  8807,  1988. 

8 . Information  Processing  - Open  Systems  Interconnection  - 

Specification  of  Abstract  Syntax  Notation  One  (ASN.l),  ISO 
8824,  1987. 

9.  Information  Processing  - Open  Systems  Interconnection  - 

Specification  of  Basic  Encoding  Rules  for  ASN.l,  ISO  8825, 
1987. 

Industrial  Technology  Institute  (ITI) 

1.  Test  Coverage  Analysis  and  Measurement  (TCAM) : A Practical 

Approach  to  Determining  Coverage,  Report  No.  ITI  TR-87-14.1, 
Industrial  Technology  Institute,  Communications  and  Network 
Laboratory,  2901  Hubbard  Road,  P.O.  Box  1485,  Ann  Arbor, 
Michigan  48109. 
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1.  SDL,  Recommendation  Z.lOO,  1988,  International 
Telecommunications  Union,  Place  des  Nations,  CH  1211,  Geneva 
20  Switzerland. 


2.  ORGANIZATIONAL  MODEL 

Conformance  and  interoperability  testing  for  GOSIP  will  be 
accomplished  in  accordance  with  the  organizational  model  described 
in  this  Clause.  This  organizational  model  consists  of  a Program 
Sponsor,  Accreditation  Authority,  the  NIST  OSI  Implementors' 
Workshop,  test  laboratories  and  their  clients.  Each  member  of 
this  model  shares  responsibilities  for  assuring  conformance  of 
products  to  GOSIP.  Under  the  rules  and  procedures  established  by 
NIST  CSL,  this  model  will  enable  a client  to  have  his  product 
tested  by  any  NVLAP  accredited  test  laboratory;  and  the  test 
results  produced  by  that  laboratory  accepted  by  NIST  CSL*  as  the 
basis  for  registration  as  a Conformance  Tested  GOSIP  Product.  The 
registration  policy  and  procedures  employed  in  this  organizational 
model  are  described  in  a companion  handbook  published  by  NIST  CSL 
[NIST  8] . 

Full  implementation  or  use  of  all  parts  of  the  organizational 
model  depends  on  the  complexity  of  the  standard  (s)  and  the 
conformance  testing  methods  applied  for  the  standard (s) . In 
circumstances  deemed  necessary  by  the  Director  of  the  NIST  CSL  (or 
his  agent) , this  report  and  registers  identified  by  this  report 
may  designate  alternate  or  supplementary  procedures,  means  of 
testing,  and  abstract  test  suites  for  testing  GOSIP  products. 

Table  1 provides  a cross-reference  of  the  parties  involved  in  the 
model,  together  with  their  respective  roles.  The  "Clause  or 
Reference"  column  provides  a cross-reference  of  each  role  with  the 
respective  clause  of  this  report  in  which  such  role  is  described. 
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Clause  or 

Reference  Role  Responsible  Party 

2.1 

Program  Sponsor 

Director,  NIST  CSL 

2.1 

Program  Operator 

Agent  of  the 
Director  of  NIST  CSL 

2.2 

Test  Laboratory  Accreditation 
Authority 

NVLAP 

3. 

Laboratory  Accreditation 
Procedures 

NIST  CSL 

2.1 

Means  of  Testing  Assessment 
Authority 

NIST  CSL/Agent 

3.2 

Means  of  Testing  Assessment 
Procedures 

NIST  CSL 

Part  II 

Abstract  Test  Suite  Review 
and  Acceptance 

NIST  CSL/Public 

6.3 

Reference  Implementation 

Review  and  Acceptance 

NIST  CSL 

2.3 

Provision  of  Means  of  Testing 

Test  System 
Suppliers 

2.4 

Conformance  Testing  Service 

Accredited  Conf. 

Test  Laboratory 

6.3 

Interoperability  Test  Suite 
Review  and  Acceptance 

NIST  CSL/Public 

6.3 

Reference  Interoperability 
Testing  Service 

NIST  CSL,  Agent,  or 
Conf.  Lab 

6.3 

1 

1 

Multivendor  Interoperability 
Testing 



GOSIP  Product 

Suppliers  & Users  | 

1 

GOSIP  Testing;  Organizational  Responsibilities 

TABLE  1 
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4. 

Abstract  Test  Suite 

Registration 

Agent  of  the 
Director  of  NIST  CSL 

4, 

Interoperability  Test  Suite 
Registration 

Agent  of  the 
Director  of  NIST  CSL 

4. 

Reference  Implementation 
Registration 

Agent  of  the 
Director  of  NIST  CSL 

4. 

Accredited  Test  Laboratory 
Registration 

Agent  of  the 
Director  of  NIST  CSL 

4. 

Means  of  Testing 

Registration 

Agent  of  the 
Director  of  NIST  CSL 

4. 

Conformance  Tested  Product 
Registration 

Agent  of  the 
Director  of  NIST  CSL 

4. 

Interoperability  Tested 

Product  Registration 

Interop.  Reg. 
Authority 

L 

Procurement  of  GOSIP 

Products 

- 

Acquisition 

Authority 

- 1 

GOSIP  Testing:  Organizational  Rasponsibilities 

TABLE  1 (continued) 


2 ® 1 Prograan  Sponsor 
2ol.l  NIST-CSL 


The  Director  of  NIST  CSL  is  the  Program  Sponsor  for  the  GOSIP 
conformance  testing  program.  The  Director  of  NIST  CSL  provides  the 
overall  direction  for  organizing,  managing,  directing,  and 
administering  the  GOSIP  Testing  Program. 

The  Director  of  NIST  CSL  has  the  authority  to: 

1)  Establish  and  maintain  the  GOSIP  conformance  testing  program 
policies  and  procedures; 

2)  Register  the  test  methods  used  in  determining  conformance  of 
products  to  GOSIP; 
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3)  Develop  and  maintain  the  procedures  to  be  followed  by  clients 
of  accredited  test  laboratories  in  order  to  attain  product 
registration ; 

4)  Issue  a certificate  of  Registration  based  on  the  results  of  a 
test  report; 

5)  Establish  the  accreditation  criteria  for  test  laboratories; 

6)  Maintain  and  periodically  publish  a register  of  products  that 
have  passed  conformance  testing,  and  a register  of  products  that 
have  passed  interoperability  testing. 

7)  Coordinate  with  other  assessment,  accreditation  and  certification 
authorities  for  the  purpose  of  harmonizing  methods  and  making 
provisions  for  mutual  recognition  of  conformance  testing  results; 

8)  Evaluate  and  resolve  disputes  on  all  matters  concerning 
conformance  testing  for  GOSIP; 

9)  Periodically  assess  the  need  for  a conformance  testing  program, 
maintain  test  method  assessment  and  test  laboratory  accreditation 
programs  for  GOSIP; 

10)  Maintain  and  publish  a register  of  accredited  test  laboratories 
recognized  by  NIST  CSL  to  perform  GOSIP  conformance  testing; 

11)  Establish  the  fees  or  rates  for  NIST  CSL  provided  products  and 
services ; and 

12)  Announce  in  the  Federal  Register  and/or  the  Commerce  Business 
Daily  the  availability  of  an  assessment  service. 

2.1.2  Agent  of  NIST-CSL 

The  Director  of  NIST-CSL  has  the  right  to  designate  an  Agent,  outside 

of  NIST,  to  be  responsible  for  conducting  the  program  of  registration 

and  assessments.  Any  such  designation  will  be  announced  in  the 

Federal  Register  or  the  Commerce  Business  Daily. 


2.2  GOSIP  Accreditation  Authority 

NVLAP  is  the  Accreditation  Authority  for  GOSIP  testing.  The  role  of 
NVLAP  is  to  inspect  and  accredit  testing  laboratories,  using  the 
laboratory  accreditation  procedures  provided  for  GOSIP  [NIST  6]. 
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2.3  Suppliers  of  the  Means  of  Testing 


Suppliers  undertake  to  develop  and  supply  to  test  laboratories  the 

means  of  testing.  Suppliers  may  be  commercial,  governmental, 

educational,  or  foreign-based  organizations. 

The  responsibilities  of  a supplier  are  to: 

1)  Develop  the  means  of  testing  for  GOSIP  protocols  in  accordance 
with  the  criteria  specified  in  this  report; 

2)  Undertake  to  maintain  the  means  of  testing  to  reflect  changes 
in  the  published  standards  and  implementors  agreements; 

3)  Obtain  and  maintain  assessment  and  registration  of  their 
product (s) ; 

4)  Pay  all  relevant  fees. 


2.4  Conformance  Test  T laboratories 

Test  laboratories  perform  conformance  testing  in  accordance  with  NIST 
CSL  approved  procedures.  Test  laboratories  may  be  commercial 
laboratories  (third-party) , vendor  laboratories  (first-party) , 
university  laboratories,  Federal,  State  or  local  Government 
laboratories,  or  foreign-based  laboratories. 

Only  test  laboratories  accredited  under  an  NIST  CSL  approved 
laboratory  accreditation  program,  or  test  laboratories  established  as 
a result  of  mutual  recognition  arrangements  with  NIST  CSL  or  NVLAP 
shall  be  recognized  by  NIST  CSL  to  do  GOSIP  conformance  testing. 

The  responsibilities  of  a test  laboratory  are  to: 

1)  Obtain  and  maintain  laboratory  accreditation  as  appropriate; 

2)  Conduct  conformance  testing  in  accordance  with  the  NIST  CSL 
prescribed  procedures; 

3)  Prepare  SCTR  and  PCTRs  in  accordance  with  NIST  CSL  prescribed 
procedures  as  a result  of  the  testing  performed; 

4)  Participate  in  proficiency  testing  as  required; 

5)  Pay  all  relevant  fees; 

6)  Participate  in  training  sessions  or  meetings  as  required  by  NIST 
CSL  to  remain  up-to-date  on  changes  to  the  conformance  testing 
procedures ; 
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7)  Provide  feedback  to  NIST  CSL  on  problems  and  improvements 
relating  to  the  conformance  testing  procedures; 

8)  Optionally,  to  become  accredited  for,  and  to  conduct,  reference 
interoperability  testing. 

2 . 5 Clients 

Clients  are  responsible  for  submitting  requests  for  product 

conformance  testing  to  an  accredited  test  laboratory  in  accordance 

with  testing  laboratory  prescribed  procedures.  The  responsibilities 

of  a client  include: 

1)  Provide  complete  and  accurate  information  to  the  test  laboratory 
for  the  performance  of  the  requested  conformance  testing; 

2)  Unless  otherwise  agreed  to  by  the  test  laboratory,  provide  the 
test  facilities  and  materials  necessary  for  testing; 

3)  Provide  a product  conforming  with  GOSIP; 

4)  Provide  copies  of  the  PCTR  and  SCTR  to  the  registration 
authority,  after  successful  conformance  testing  by  an  accredited 
test  laboratory,  for  the  purpose  of  registration. 


2.6  Criteria  for  NIST  CSL*  Registration  of  a Conformant  GOSIP  Product 

1)  Submit  to  NIST  CSL*  a PICS  for  a product  claiming  to  conform  to 
GOSIP  specifications; 

2)  Provide  Protocol  Conformance  Test  Report (s)  and  System 
Conformance  Test  Report  for  the  product; 

3)  These  reports  are  to  be  produced  after  successful  conformance 
testing  by  an  accredited  test  laboratory  using  a registered  means 
of  testing,  including  registered  abstract  test  suites. 

4)  Pay  the  appropriate  registration  fees. 


3 . ACCREDITATION 

NIST  CSL*  will  carry  out  its  responsibilities  for  conformance  testing 
through  test  laboratories  judged  to  be  competent  to  objectively 
perform  the  necessary  tests.  Laboratory  accreditation  serves  as  a 
basis  for  determining  laboratory  competence.  The  purpose  is  to  insure 
that  testing  facilities  are  available  for  obtaining  an  unbiased 
assessment  of  products  regarding  GOSIP  conformance.  Clause  3.1 
outlines  these  objectives. 
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To  ensure  that  test  laboratories  are  using  tools  which  are  capable 
of  performing  accurate  and  adeguate  assessments,  NIST  CSL  defines  in 
clause  3.2  the  requirements  upon  each  party  involved. 


3.1  Test  Laboratory  Accreditation 

Wherever  appropriate  for  a given  GOSIP  protocol,  NIST  CSL  will  draw 
upon  the  NIST  National  Voluntary  Laboratory  Accreditation  Program 
(NVLAP)  as  the  basis  for  accrediting  test  laboratories.  NIST  CSL 
shall  establish  technical  criteria  for  laboratory  accreditation. 
Technical  experts  for  assessing  laboratory  competence  (assessors)  may 
be  drawn  from  qualified  Government,  academic,  industrial,  or 
independent  organizations. 

The  objectives  of  laboratory  accreditation  are  tos 

1)  Identify  technically  competent  testing  services; 

2)  Assess  and  evaluate  each  test  laboratory  accredited  to  do  testing 
for  conformance  to  GOSIP  by; 

a)  Conducting  periodic  laboratory  proficiency  testing  to  identify 
testing  capability, 

b)  Initially,  and  periodically  thereafter,  conducting  on-site 
assessments  to  deteoaine  compliance  with  the  accreditation 
criteria,  and 

c)  Conducting  visits  to  verify  reported  changes  in  the 
laboratory’s  personnel,  facilities,  and  operations,  or  to 
explore  possible  reasons  for  poor  performance  in  testing 
practices ; 

3)  Insure  that  the  test  laboratory  has  adequate  quality  control, 
facilities,  equipment  and  personnel  to  conduct  testing; 

4)  Determine  that  the  test  laboratory  staff  is  adequately  trained 
in  using  the  appropriate  registered  Means  of  Testing,  following 
the  prescribed  conformance  testing  procedures; 

5)  Insure  that  adequate  records  are  maintained  to  support  the 
testing  performed  and  that  test  reports  are  produced  to  provide 
the  necessary  information  for  determining  conformance  to  GOSIP; 

6)  Notify  the  test  laboratory  of  deficiencies; 

7)  Establish  criteria  and  procedures  for  test  laboratories  to  both 
obtain  and  maintain  accreditation. 
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3.2  Means  of  Testing  Assessment 


Prerequisites  of  the  methodology  defined  below  are  that  an  abstract 
test  suite  (ATS)  exists,  standardized  or  not,  which  has  been  publicly 
reviewed,  with  respect  to  the  GOSIP  PICS,  amended  as  necessary,  and 
is  registered  by  NIST  CSL*. 


3.2.1  Registered  Abstract  Test  Suites 

A recognized  abstract  test  suite  shall  be  registered  by  the  NIST  CSL* 

(hereafter  called  a registered  ATS) . 

Amendment  of  an  ATS  is  defined  to  be: 

1)  delete  test  cases  which  are  not  applicable  to  a profile; 

2)  specify  constraints  based  upon  agreements  of  the  OIW  which  may 
be  made  either  more  rigorous  or  less  rigorous; 

3)  specify  additional  test  cases  as  necessary  to  encompass  all 
mandatory  and  optional  features  using  criteria  stated  in  Part 
II  of  this  Report; 

4)  Registration  of  the  ATS  shall  be  staged  to  accommodate 
improvements  in  the  state  of  the  art  of  test  suite  development. 
Each  ATS  will  be  harmonized  with  the  ISO  work  and  will  reach 
stability  with  the  International  Standard. 

3.2.2  Means  of  Testing  Supplier 

Suppliers  of  a Means  of  Testing  shall: 

1)  Request  assessment  of  a product  by  submitting  the  forms  and  fees 
as  required  by  the  MOT  Assessment  and  Registration  Authority; 

2)  Identify  the  mapping  between  each  abstract  test  case  and  the 
supplier's  realization  of  it; 

3)  Arrange  for  a mutually  satisfactory  date  for  assessment  of 
the  MOT; 

5)  Demonstrate  to  the  satisfaction  of  the  MOT  Assessment  and 
Registration  Authority,  that  a set  of  executable  test  cases 
corresponding  to  a set  of  test  cases  selected  from  the 
registered  ATS  achieve  the  test  purposes  and  exhibit  the  dynamic 
behavior  specified  when  executed  against  an  implementation  of 
the  corresponding  OSI  protocol; 

6)  Have  a quality  management  program  that  assures  maintenance  and 
convergence  of  their  product (s)  such  that  the  product (s)  meet 
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the  requirements  of  registered  ATS(s)  and  the  Means  of  Testing 
Assessment  and  Registration  Authority; 

7)  Have  adequate  mechanisms  for  distribution  of  updates  and 
corrections  to  test  laboratories  employing  the  supplier 
products,  in  accordance  with  NIST  CSL  staged  improvement 
procedures,  and  mechanisms  to  notify  test  laboratories  of  known 
problems  in  products. 

3.2.3  MOT  Assessment  and  Registration  Authority 

The  MOT  Assessment  and  Registration  Authority  shall: 

1)  Upon  receipt  of  a request  from  an  MOT  supplier,  and  required 
fees,  arrange  for  a mutually  acceptable  date  for  assessing  the 
product ; 

2)  Select  one  or  more  assessors  from  a group  of  experts  who 
have  no  vested  interest  in  the  product  and  are  neutral  with 
respect  to  the  results  of  the  assessment,  are  technically 
competent  with  respect  to  the  OSI  protocol (s),  GOSIP 
requirements,  and  the  conformance  test  methodology 
employed.  Assessors  may  be  drawn  from  the  private  and 
public  sectors  (including  agencies  of  the  Federal 
government)  to  serve  as  independent  assessors  of  the 
product  to  be  accredited; 

3)  Assess  the  Means  of  Testing  using  either  a reference 
implementation,  or  an  otherwise  available  implementation  of  the 
protocol (s).  Tests  are  selected  for  execution  according  to  the 
GOSIP  Means  of  Testing  Assessment  Handbook  [NIST  7]. 

3.2.4  Role  of  the  MOT  Supplier 

Using  the  test  cases  selected,  the  supplier  shall: 

1)  provide  the  assessor  with  the  facility  to  select  and  execute 
test  cases  on  the  MOT  under  assessment; 

2)  execute  test  cases  selected  by  the  assessor (s) ; 

3)  produce  log  files  showing  detailed  protocol  exchange  behavior; 

4)  make  these  log  files  available  to  the  assessor (s)  for  their 
analysis. 


3.2.5  Role  of  the  Assessors 

Using  the  reports,  conformance  log(s)  and  the  MOT  Assessment 
Handbook,  the  assessor (s)  shall: 
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1)  review  the  conformance  log(s)  produced  by  the  product  supplier 
to  assure: 

a)  the  dynamic  behaviors  identified  in  the  corresponding  test 
cases  of  the  registered  ATS  are  reflected  in  the  conformance 
log; 

b)  verdicts  reported  in  the  logs  are  correct  with  respect  to  the 
verdicts  identified  in  the  registered  ATS; 

2)  Directly  oversee  the  execution  of  a percentage  of  the  tests; 

3)  If  the  results  of  the  assessment  are  affirmative  for  test  cases 
executed,  the  assessors  shall  recommend  registration  of  the  MOT. 


4)  If  the  initial  results  of  the  assessment  are  negative,  then  the 
provisions  of  the  MOT  Assessment  Handbook  shall  be  followed. 


4 . REGISTERS  EMPLOYED 

Essential  to  the  operation  of  the  provisions  of  this  report  are 
registers  maintained  by  NIST  CSL*.  The  names  of  the  registers  and 
a brief  description  of  each  are  below. 

Abstract  Test  Suites  for  GOSIP 

For  each  GOSIP  protocol  a test  suite  composed  of  test  purposes  or 
abstract  test  cases  is  placed  in  the  public  domain  and  designated  as 
the  Registered  Abstract  Test  Suite.  The  tests  are  updated  from  time 
to  time  to  harmonize  with  International  Standard  test  suites. 

Assessed  Means  of  Testing  for  GOSIP 

For  GOSIP  profiles  or  substacks,  the  means  of  testing  are  assessed 
according  to  the  criteria  published  in  a companion  handbook  [NIST  7]. 
The  treatment  of  derived  implementations  of  an  MOT  is  described  in 
the  same  handbook.  Any  qualified  system  may  be  registered  for  use  in 
GOSIP  conformance  testing. 

Laboratories  Accredited  for  GOSIP  Conformance  Testing 

Any  testing  laboratory  which  complies  with  the  provisions  of  this 
FIPS  and  a companion  handbook  [NIST  6],  as  administered  by  the 
National  Voluntary  Laboratory  Accreditation  Program,  may  be 
accredited  and  added  to  the  register.  Compliance  includes  the 
operation  of  a registered  Means  of  Testing  realizing  one  or  more 
registered  Abstract  Test  Suites. 
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Conformance  Tested  GOSIP  Products 


GOSIP  products  which  have  been  successfully  tested  by  an  accredited 
test  laboratory  using  a registered  Means  of  Testing,  including 
registered  Abstract  Test  Suites,  may  be  added  to  the  register.  The 
treatment  of  derived  implementations  is  described  in  clause  6.2.3 
below.  Addition  to  this  register  is  required  before  GOSIP 
interoperability  testing  is  conducted. 

Interopercibilitv  Test  Suites  for  OSI  Products 

For  each  GOSIP  application  a test  suite  composed  of  test  purposes  is 
placed  in  the  public  domain  and  designated  as  the  Registered 
Interoperability  Test  Suite.  The  tests  are  updated  from  time  to  time 
to  achieve  international  harmonization. 

Reference  Entities  for  Interoperability  Testing 

For  each  GOSIP  application  or  intermediate  system  and  its  supporting 
stack,  one  implementation  which  has  successfully  passed  conformance 
testing  and  meets  the  selection  criteria  specified  is  designated  as 
the  reference  entity.  Reference  entities  are  used  by  NIST  in  the 
conduct  of  interoperability  testing  with  OSI  product  suppliers. 

Interworking  GOSIP  Products 

Products  which  have  been  successfully  tested  for  interoperability 
against  the  NIST  CSL*  Reference  Implementation,  by  an  OSI  product 
supplier  over  a LAN  or  WAN,  and  using  NIST  CSL*  registered  Test 
Suites  may  be  registered. 

Interoperability  Test  and  Registration  Services 

Any  organization  may  offer  to  define  procedures  for  the  conduct  of 
multivendor  interoperability  testing  and  to  register  the  results  of 
testing.  Any  such  organization  which  is  approved  by  NIST  is  entered 
onto  this  meta-register.  The  number  of  NIST  approved 
Interoperability  Services  is  not  limited.  Criteria  for  NIST  approval 
are  given  in  the  GOSIP  Registration  Criteria  handbook  [NIST  8]. 


5.  EMPLOYMENT  OF  THE  OSI  CONFORMANCE  TESTING  METHODOLOGY 

ISO's  OSI  Conformance  Testing  Methodology  and  Framework  [ISO  1]  is  an 
evolving  multi-part  international  standard.  It  defines  terminology, 
concepts,  and  requirements  for:  (1)  other  standards  bodies  who  are 
responsible  for  producing  abstract  test  suites;  (2)  suppliers  of  a 
means  of  testing  (real  test  systems) ; (3)  test  laboratories;  (4) 
clients  of  test  laboratories;  (5)  information  exchanged  between  test 
laboratories  and  their  clients;  and  (6)  proformas  for  test  reports 
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(whose  content  is  outlined  in  Parts  4 and  5 of  the  ISO  Conformance 
Methodology  [ISO  1]  and  is  detailed  in  standards  associated  with 
abstract  test  suites) . 

This  standard  provides  the  basis  for  the  conformance  aspects  of  the 
GOSIP  testing  program;  however  in  certain  instances  the  work  of  ISO 
is  not  applicable  to  this  report.  For  example,  when: 


1) 

Standardized 
protocol , 

abstract 

test 

suites 

do 

not 

exist 

for 

a GOSIP 

2) 

Standardized 

abstract 

test 

suites 

do 

not 

test 

for 

features 

mandated  by  GOSIP, 

3)  ISO  Conformance  methodology  does  not  address: 

a)  multi-party  or  multi-peer  protocols, 

b)  multi-layer  test  methods, 

c)  physical  media,  and 

4)  Interoperability  testing  is  required. 

The  means  of  testing  employed  by  accredited  test  laboratories  may  be 
a product  of  either  the  public  sector  or  private  sector,  if  the 
latter  is  a commercially  available  product. 

In  general,  this  report  references  abstract  test  suites  (or  test 
methodology)  for  GOSIP  which  are  based  on  the  NIST  OSI  Implementors ' 
Workshop  Agreements  [NIST  2,  NIST  9].  They  may  be  produced  by  the 
public  sector,  including  standards  bodies,  or  the  private  sector. 
Any  registered  abstract  test  suite  or  other  test  methodology  employed 
shall  be  in  the  public  domain,  without  protection  of  copyright. 

This  report  provides  criteria  for  assessment  of  the  coverage  and 
quality  of  test  suites.  As  standardized  abstract  test  suites,  and 
their  derived  executable  test  suites,  become  available,  they  will  be 
assessed  for  their  adequacy  under  the  criteria  in  this  report,  in 
order  that  they  may  be  approved  for  use  in  testing  GOSIP  products. 

Staged  improvements  to  the  abstract  test  suites  will  be  conducted  in 
accordance  with  the  GOSIP  registration  criteria  [NIST  8].  The 
intention  is  ultimately  to  harmonize  with  International  Standard  OSI 
test  suites. 


6 . TESTING  FRAMEWORK 

6.1  Relation  Between  Testing  Phases 

The  immediate  goal  of  testing  communications  products  which  claim  to 
conform  to  the  GOSIP  specifications  is  to  qualify  them  for  inclusion 
in  either  the  Register  of  Conformance  Tested  GOSIP  Products,  the 
Register  of  Interworking  GOSIP  Products,  or  both.  The  phases  of 
testing  coinciding  with  registration  are  conformance  testing  and 
interoperability  testing,  respectively. 
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1) 


Successful  conformance  testing  by  an  accredited  test  laboratory 
using  a registered  Means  of  Testing,  including  registered 
Abstract  Test  Suites,  leads  to  addition  to  the  Register  of 
Conformance  Tested  GOSIP  Products. 

2)  Successful  interoperability  testing  against  a Registered 
Reference  Entity,  leads  to  addition  to  the  Register  of 
Interworking  GOSIP  Products . 

3)  Successful  interoperability  testing  with  other  compatible 
products  using  a recognized  methodology,  that  is,  one  on  the 
Register  of  Interoperability  Test  and  Registration  Services, 

leads  to  publicly  accessible  documentation  of  pair-wise  multi- 
vendor interoperability. 

Requirements  for  GOSIP  product  suppliers  to  enter  each  phase  of 
testing  follow. 

Conformance 


1)  Develop  a GOSIP  conformant  product,  or  a partial  stack  thereof, 
which  is  testable  using  at  least  one  of  the  methods  specified  in 
this  report. 

2)  Provide  a PICS  to  an  accredited  test  laboratory  specifying 
functionality  supported  in  the  implementation  for  each  protocol 
in  the  stack. 

3)  Provide  a PIXIT  to  the  accredited  test  laboratory  for  the 
stack/substack . 

4)  For  stacks  which  build  on  substacks  which  have  been  previously 
conformance  tested  within  the  GOSIP  testing  process,  provide  an 
SCTR,  PCTR  and  evidence  of  Registration  for  the  previously 
tested  functionality.  For  instance  if  the  session  protocol  is 
to  be  tested  over  transport  class  4 protocol  (TP4) , an  SCTR, 
PCTR  and  certificate  of  registration  should  be  furnished  for  the 
TP4  substack,  as  evidence  that  all  the  supporting  protocols  do 
not  need  to  be  completely  retested. 

Interoperability  Testing 

Entry  on  the  NIST  CSL*  register  of  conforming  GOSIP  products  is  a 
prerequisite  to  GOSIP  interoperability  testing.  Interoperability 
testing  against  the  NIST  CSL*  Reference  Implementation  occurs  if  and 
only  if  a reference  implementation  is  registered  for  a specific 
protocol  or  stack.  There  is  no  procedural  distinction  drawn  between 
interoperability  testing  against  the  NIST  CSL*  reference  and  pairwise 
GOSIP  product  supplier  interoperability  testing. 
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Detailed  mechanisms  applicable  to  conformance  and  interoperability 
testing  and  the  assessment  thereof,  are  given  in  the  following 
clauses. 

6 . 2 Conformance  Testing 
6.2.1  What  Is  To  Be  Tested 

Products  of  the  following  types  may  be  made  available  for  conformance 
testing: 

- 7 layer  Application  stacks, 

- 7 layer  Relay  stacks, 

- 4 layer  transport  stacks, 

- 2 or  3 layer  Network  stacks, 

- 3 layer  Intermediate  System  stacks. 

This  structuring  explicitly  recognizes  test  platforms  (substacks) 
employed  by  existing  testing  technology. 

In  conformance  testing,  previously  tested  End  System  substacks  may 
be  carried  forward  into  larger  substacks.  In  such  cases, 
comprehensive  retesting  of  previously  tested  functionality  is  not 
necessary:  Basic  Interconnection  Testing  is  sufficient,  providing 

that  Protocol  Conformance  Test  Reports  are  furnished  for  previously 
tested  protocols.  However,  the  same  principle  does  not  work  in 
reverse.  If  a 7 layer  stack  is  tested,  using  Single-layer  embedded 
methods  for  the  lower  layers,  and  a substack  is  subsequently 
extracted  and  added  as  a component  of  a different  7 layer  stack,  then 
the  whole  of  the  new  stack  shall  be  comprehensively  tested.  This  is 
because  embedded  testing  alone  does  not  provide  sufficient  confidence 
in  a lower  layer  protocol  when  considered  outside  of  its  original 
stack  context. 

The  complete  set  of  full  stack  profile  possibilities  for  GOSIP  1.0 
is  given  in  Part  II,  clause  1.5.  To  take  as  an  example  stack  number 

1. 

FTAM/ACSE/Presentation/Session/TP4/CLNP/LLCl/8802 . 3 
Conformance  testing  of  substacks  may  proceed  as  follows. 

1)  The  subnetwork  protocols  (LLCl/8802 . 3 ) may  be  tested  (although 
this  is  not  separately  mandated)  and  a System  Conformance  Test 
Report  (SCTR)  is  produced. 

2)  TP4/CLNP  is  offered  for  testing  over  802.3;  the  SCTR  is  provided 
to  demonstrate  conformance  to  8802.3.  Basic  interconnection 
testing  is  conducted  to  establish  the  basic  workability  of  the 
substack.  CLNP  is  tested  by  coordinated  single-layer  embedded 
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means;  TP4  is  tested  by  coordinated  single  layer  means.  If 
conformance  to  both  protocols  is  established,  a second  SCTR  is 
produced  for  the  substack. 

3)  FTAM  is  offered  for  testing  over  TP4;  the  second  SCTR  is 
provided  to  demonstrate  conformance  to  TP4,  CLNP  and  8802.3. 
Basic  interconnection  testing  is  conducted  to  establish  the 
basic  workability  of  the  stack  (as  an  FTAM  Initiator  or  as  an 
FTAM  Responder) . Session,  presentation  and  ACSE  are  tested  by 
remote  single-layer  embedded  means  for  use  with  FTAM  Responders, 
and  by  distributed  single-layer  embedded  means  for  use  with  FTAM 
Initiators.  An  FTAM  Responder  is  tested  by  remote  single-layer 
means;  an  FTAM  Initiator  is  tested  by  distributed  single-layer 
means.  If  conformance  to  all  protocols  is  established,  an  SCTR 
is  produced  for  the  FTAM  Initiator  and  Responder  stacks. 

If  it  is  subsequently  desired  to  test  X.400  in  stack  8 (Part  II, 
Clause  1.5)  then  the  SCTR  may  be  taken  from  step  2)  above,  as  proof 
of  conformance  of  TP4/CLNP/LLC1/8802 . 3 . Basic  interconnection 
testing  is  performed  to  establish  the  basic  workability  of  the  stack. 
The  session,  RTS  and  PI  protocols  are  tested  by  distributed  single- 
layer embedded  means.  The  P2  protocol  is  tested  by  distributed 
single-layer  means.  If  conformance  is  established,  an  SCTR  is  issued 
for  the  MHS  End  System  stack. 

6.2e2  How  Testing  Is  Conducted 

These  GOSIP  Testing  Guidelines  are  guided  by  the  recommendations 
given  in  the  OSI  Conformance  Testing  Methodology  and  Framework  [ISO 
1] . MOT  suppliers  and  conformance  test  laboratories  are  expected  to 
be  familiar  with  Part  5 which  provides  Requirements  on  Test 
Laboratories  and  Clients  for  the  Conformance  Assessment  Process,  and 
with  the  General  Principles  and  Abstract  Test  Methods  defined  in 
Parts  1 and  2 . 

6 . 2 . 2 . 1 Testing  Elements 

For  each  stack  supplied,  the  product  configuration  determines  the 
test  method  used.  Part  1 defines  Abstract  Test  Methods  which  may  be 
employed  and  provides  guidance  on  their  applicability  to  real  test 
systems.  Central  to  the  concept  of  conformance  testing  is  the 
ability  to  control  and  observe  events  of  the  Implementation  Under 
Test  (lUT)  within  the  System  Under  Test  (SUT) . Every  test  method 
has,  at  minimum,  a Point  of  Control  and  Observation  (PCO)  through  the 
medium  which  connects  the  means  of  testing  with  the  SUT.  This  is  the 
point  at  which  the  means  of  testing  injects  valid  and  invalid 
Protocol  Data  Units  (PDUs)  of  the  protocol  or  protocols  under  test, 
and  observes  PDUs  returned  from  the  SUT.  Any  SUT  which  is  accessible 
only  through  this  PCO  is  testable  using  the  Remote  method.  The 
distributed  and  coordinated  methods  provide  extra  control  and 
coordination  with  the  SUT,  and  this  is  usually  effected  through  test 
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coordination  procedures  which  exist  between  the  means  of  testing  and 
the  SUT.  In  all  cases  the  initial  stimulus  for  testing  comes  from 
the  means  of  testing.  For  the  remote  method,  the  SUT  is  stimulated 
by  protocol  data  units  received  via  an  underlying  OSI  service.  For 
the  distributed  method,  the  SUT  is  stimulated  directly  at  the  (N) 
service,  by  coordination  interactions  between  the  Means  of  Testing 
and  the  SUT.  For  the  coordinated  method  the  SUT  is  stimulated  to 
generate  (N) -PDUs  as  a result  of  prior  interactions  between  the  lower 
tester  and  upper  tester,  by  means  of  a test  management  protocol.  The 
set  of  acceptable  Abstract  Test  Methods  for  specific  protocols  in  the 
GOSIP  profile  is  given  in  Part  II  of  this  report. 

The  OSI  Conformance  Testing  Methodology  and  Framework  structures  a 
test  suite  into  Basic  Interconnection,  Capability  and  Behavior  tests. 
The  first  two  of  these  categories  are  proper  subsets  of  the  third 
(although  the  test  purposes  may  be  different) . In  the  limit. 
Behavior  tests  provide  exhaustive  coverage  “ a limit  which  is  by  no 
means  practical.  Basic  Interconnection  tests  are  used  in  practical 
testing  situations  to  check  out  the  basic  operation  of  the  linkage 
between  the  SUT  and  the  means  of  testing,  and  as  such  are  not 
mandatory  for  coverage  purposes.  Capability  tests  are  intended  to 
provide  100  per  cent  'breadth'  of  test  coverage,  i.e.,  at  least  one 
test  per  function  specified  in  the  protocol/NIST  Implementor's 
Agreements  for  all  mandatory  and  optional  features.  Behavior  tests 
provide  extra  depth  of  coverage  over  all  of  the  capabilities.  In 
regard  to  coverage,  options  in  a protocol  are  not  optional  in  a test 
suite.  Tests  must  be  available  for  each  option,  even  though  they  may 
not  be  selected  for  use  with  a particular  lUT. 

The  administration  of  GOSIP  testing  includes  recognition  and 
registration  of  abstract  test  suites  for  each  GOSIP  protocol. 
Specific  provisions  are  given  in  the  GOSIP  Means  of  Testing 
Assessment  Handbook  [NIST  7]. 

6 . 2 . 2 . 2 The  Process 

The  conformance  assessment  process  includes: 

- Preparation  for  testing, 

- Test  operations, 

- Test  report  production. 

The  following  clauses  provide  a brief  description  of  these  phases. 
A comprehensive  description  is  given  in  Part  5 of  IS  9646. 
Accreditation  of  conformance  testing  laboratories  is  directly  based 
on  the  use  of  that  test  methodology. 


6. 2. 2. 3 Preparation  For  Testing 

The  preparation  phase  defines  general  documentation  and  configuration 
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steps  which  must  be  carried  out  prior  to  conducting  a test  campaign. 
This  includes  furnishing  of  GOSIP  PICS,  PIXIT,  and  any  vendor 
configuration  requirements  to  a test  laboratory. 

6 . 2 . 2 . 4 Test  Operations 

The  test  operations  phase  includes  static  conformance  assessment, 
test  selection  and  parameterization,  followed  by  dynamic  testing. 
Test  selection  is  based  on  options  claimed  to  be  supported  in  the 
lUT,  as  documented  in  the  GOSIP  PICS.  Parameterization  of  selected 
tests  is  based  on  information  provided  in  the  PIXIT.  Dynamic  testing 
occurs  using  the  executable  realization  of  the  selected  abstract  test 
cases,  in  which  each  test  case  is  executed  against  the  lUT  to  produce 
a Verdict.  Any  ’Inconclusive*  verdicts  may  be  resolved  into  ’Pass' 
or  ’Fail’  at  this  time. 

6. 2. 2. 5 Test  Report  Production 

Test  report  production  is  a phase  of  assessment  of  the  results  of 
dynamic  testing,  and  production  of  System  Conformance  Test  Report  and 
Protocol  Conformance  Test  Report (s) , recording  the  verdicts 
determined  during  the  dynamic  assessment. 

6 . 2 . 2 . 6 Addressing 

The  testing  of  addressing  includes  a static  check  against  the  PIXIT 
for  employment  of  the  GOSIP  addressing  structure,  and  Basic 
Interconnection  Tests  to  ensure  that  addressing  is  accurate. 


6.2e2.7  Evaluation  of  Conformance  Testing 

Detailed  criteria  for  the  evaluation  of  conformance  testing  are 
provided  by  the  GOSIP  Means  of  Testing  Assessment  Handbook  [NIST  7], 
for  test  systems;  and  the  NVLAP  Handbook:  Operational  Requirements  of 
the  Laboratory  Accreditation  Program  for  GOSIP  Conformance  Testing 
[NIST  6],  for  conformance  testing  laboratories. 

6.2.3  Treatment  of  Derived  Products 

In  certain  circumstances  a GOSIP  Means  of  Testing  or  a GOSIP  Product 
may  be  derived  from  a tested  ’base’  implementation,  without  requiring 
further  formal  testing.  The  following  conditions  must  hold: 

(a)  The  registration  date  for  the  base  implementation  has  an 
expiration  date  at  least  six  months  beyond  the  date  of 
derivation. 

(b)  The  host  and  target  computer  systems  of  the  base  and  derived 
GOSIP  Implementations  have  compatible  instruction  sets  and 
operating  systems.  Common  examples  of  compatible  instruction 
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sets  and  operating  systems  are  two  different  computer  system 
models  in  a manufacturer's  product  line  or  the  computer  systems 
produced  by  different  manufacturers  that  use  the  same  hardware 
mechanisms  and  operating  systems. 

(c)  The  GOSIP  MOT  or  Implementation  proposed  for  registration  was 
derived  from  the  base  implementation  by  changes  that  are  within 
the  scope  of  accepted  software  maintenance  practices.  Arguments 
along  this  line  should  be  included,  in  writing,  with  the 
application. 

(d)  The  PCTR  and  SCTR  for  the  GOSIP  Implementation  are  either  the 
same  as  the  base  implementation  or,  if  there  are  minor 
differences,  these  differences  are  justified  as  being  within  the 
scope  of  accepted  software  maintenance  practices. 

(e)  The  base  implementation  was  assessed  in  accordance  with  NIST 
CSL*  procedures  and  is  registered  with  the  NIST  CSL*. 

A derived  implementation  may  lose  its  registration  if  it  is 

challenged  successfully.  Such  challenges  are  described  in  the 

'Appeals*  section  of  the  GOSIP  Registration  Criteria  [NIST  8]. 


6.3  Interoperability  Testing 

At  present,  no  authoritative  national  or  international  forum  for 
interoperability  testing  has  emerged.  Consequently  there  is  no 
widely  accepted  consensus  on  methods  or  results,  and  no  authoritative 
references  on  the  conduct  of  interoperability  testing.  As  and  when 
such  an  authoritative  consensus  emerges  NIST  CSL  intends  to  harmonize 
with  accepted  methods.  For  the  time  being  the  following  clauses 
define  NIST  CSL  requirements  for  interoperability  testing  systems. 

6.3.1  What  Is  Tested 

Products  made  available  for  interoperability  testing  may  be: 

- 7 layer  Application  stacks, 

- 7 layer  Application  Relay  stacks, 

- 3 layer  Intermediate  System  stacks. 

In  the  case  of  End  Systems,  interoperability  testing  proceeds  by 
pairwise  operation  of  compatible  GOSIP  systems.  For  instance, 
supplier  A wishing  to  test  an  FTAM  Initiator  against  supplier  B 
should  ensure  first  that  B's  product  provides  FTAM  Responder 
capability  with  a compatible  GOSIP  profile.  Moreover  if  B provides 
sender  only,  then  A must  be  capable  of  receiving.  It  is  for  this 
reason  that,  in  the  same  way  as  with  conformance  testing,  a static 
analysis  phase  is  necessary  to  determine  whether  testing  can  proceed 
at  all. 
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Interoperability  testing  with  Intermediate  Systems  (IS)  operates  on 
a multi-peer  basis;  pairs  of  End  Systems  communicate  through  one  or 
more  3 layer  Intermediate  Systems.  An  IS  must  be  capable  of  working 
with  each  End  System  on  each  supported  subnetwork,  and  of  routing 
data  between  pairs  of  End  Systems.  In  a complex  concatenated 
network,  an  IS  must  also  route  data  from  and  to  other  ISs. 
Interoperability  testing  with  Message  Transfer  Agent  relay  entities 
proceeds  in  a similar  manner  to  Intermediate  System  testing,  on  a 
multi-peer  basis. 

6.3.2  How  Testing  Is  Conducted 

The  interoperability  testing  requirements  of  U.S.  GOSIP  are  grounded 
in  the  use  of  the  following  registers: 

- the  Register  of  GOSIP  Reference  Implementations 

- the  Register  of  Interoperability  Test  Suites 

- the  Register  of  Interoperability  Testing  Services 

- the  Register  of  Interoperating  GOSIP  products 


6.3.2. 1 Requirements  of  an  Interoperability  Testing  Suite 

In  order  to  be  entered  onto  the  register,  an  Interoperability  Test 
Suite  must: 

1)  be  freely  available  in  the  public  domain  without  copyright 
protection, 

2)  be  subject  to  public  review, 

3)  be  capable  of  exercising  the  mandatory  and  optional  services  of 
each  GOSIP  application, 

4)  describe  the  purpose  of  each  test  and  procedures  by  which  the 
test  purpose  can  be  realized, 

5)  specify  what  constitutes  a 'pass*  or  'successful  execution*  for 
each  test,  and, 

6)  be  supported  by  an  organization  recognized  by  NIST  CSL. 

For  each  GOSIP  application,  only  one  Interoperability  Test  Suite  may 
be  registered.  When  a Test  Suite  becomes  qualified  it  will  be 
provisionally  registered  until  the  next  GOSIP  Version  release.  It 
will  be  reviewed  and  updated  at  that  time.  Staged  improvements 
leading  to  harmonization  proceed  in  this  way  until  the  completed  Test 
Suite  is  fully  registered.  Registration  remains  current  while  the 
Implementation  Agreements  or  the  base  standards  remain  valid.  If 
more  than  one  valid  Interoperability  Test  Suite  becomes  available  for 
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a particular  application  stack,  then  one  only  will  be  selected  by 
NIST  CSL*  for  registration. 

6. 3. 2. 2 Requirements  of  an  Interoperability  Testing  Service 

In  the  same  way  as  with  Conformance  Testing,  Interoperability  Testing 
can  be  characterized  as  having  the  three  phases  of  preparation,  test 
operations  and  test  report  production.  In  order  to  become 
registered,  any  fomm  seeking  to  offer  an  Interoperability  Testing 
Service  must  meet  the  following  criteria: 

1)  Be  an  organization  recognized  by  NIST  CSL. 

2)  Use  a registered  Interoperability  Test  Suite. 

3)  Arrange  for  a bilateral  agreement  to  test  between  each  pair  of 
GOSIP  product  suppliers  (or  multilateral  in  the  case  of 
Intermediate  Systems  testing) . 

4)  Conduct  a static  analysis  phase  which  involves  the  selection  of 
a common  subset  of  the  GOSIP  tests  including  all  of  the 
mandatory  tests. 

5)  Conduct  a dynamic  analysis  phase  in  which  both  GOSIP  product 
suppliers  are  in  agreement  concerning  the  outcome  of  each  test. 
At  the  discretion  of  one  or  more  of  the  GOSIP  product  suppliers, 
an  Interoperability  Testing  campaign  may  be  terminated  before 
the  Test  Report  is  produced. 

6)  Issue  a test  report  which  identifies  each  GOSIP  product 
supplier,  describes  the  product  including  the  supporting  stack 
of  protocols,  and  provides  a list  of  the  tests  executed  with  a 
verdict  for  each  test.  The  verdict  may  be  * pass'  or  'fail'. 
Any  fail  verdict  must  be  accompanied  by  an  explanation  outlining 
the  cause  of  failure. 

7)  At  the  request  of  NIST  CSL*,  a copy  of  the  test  report  resulting 
from  any  bilateral  or  multilateral  agreement  made  under  the 
auspices  of  the  Interoperability  Testing  Service.  A nominal  fee 
may  be  charged  for  each  report  supplied.  Each  GOSIP  product 
supplier  may  require  limitations  on  the  use  for  which  a test 
report  is  employed. 


In  cases  where  Federal  Government  Agencies  find  a persistent  lack  of 
interoperability  among  products  registered  as  interoperable,  appeals 
may  be  made  as  follows: 

1)  To  the  vendor,  or  vendors  of  the  inoperable  products,  who  shall 
make  every  effort  to  make  good  on  their  warranty. 
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2)  To  the  Interoperability  Test  and  Registration  Service  who,  after 
investigation  may  remove  the  product  pair  from  the  register. 

3)  To  NIST  CSL*  who  may  require  to  witness  testing  of  either  or 
both  of  the  products  involved,  under  the  auspices  of  the 
Interoperability  Test  and  Registration  Service,  in  the  original 
pairing,  or  in  any  other  pairings  required  by  NIST  CSL*.  In  the 
event  that  NIST  CSL*  and  the  procuring  Agency  remain  unsatisfied 
then  the  Interoperability  Test  and  Registration  Service  may  have 
its  registration  revoked. 


6-3o3  Treatment  of  Derived  Implementations 

For  the  purpose  of  interoperability  testing,  no  distinction  shall  be 
made  for  derived  implementations.  Any  product  registered  should  be 
subject  to  pairwise  testing. 

6.4  Criteria  for  Registration  as  a Reference  Entity 

NIST  shall  maintain  a register  of  reference  entities  with  which 
interoperability  testing  is  mandated.  If  no  reference  entity  is 
registered,  then  no  interoperability  testing  for  a GOSIP  protocol  is 
mandated.  Criteria  for  inclusion  in  this  register  follow.  The 
criteria  for  inclusion  are  presented  in  a ranked  order. 
Specifically,  the  first  criterion  is  more  important  than  subsequent 
criteria;  if  alternatives  are  identified,  then  the  first  alternative 
is  more  important  than  subsequent  alternatives  (e.g.,  l.b  or  l.c) . 

1)  Profile  Implemented: 

a)  shall  implement  all  mandatory  features;  and 

b)  all  optional  features  specified  in  GOSIP;  or 

c)  an  identified  subset  of  optional  features  specified  in  GOSIP. 

2)  GOSIP  Testing: 

a)  Conformance:  shall  pass  all  conformance  tests  for  mandatory 

and  optional  features  implemented;  and 

b)  Interoperability:  shall  have  demonstrated  interoperability 

with  at  least  three  suppliers  implementations  of  GOSIP 
products . 

3)  Availability: 

a)  shall  be  in  the  public  domain;  or 

b)  shall  be  publicly  available  to  all  potential  users  and 
interested  parties  (not  unduly  restricted  from  use  by 
manufacturers,  academia.  Government,  or  other  users  due  to 
legal  considerations,  license  constraints  or  cost) . 


If  an  implementation  is  available  which  is  deficient  in  some  of  the 
above  requirements,  then  at  the  option  of  NIST  CSL*  it  may  be 
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provisionally  registered.  Provisionally  registered  Reference 
Implementations  shall  be  restricted  to  use  for  dynamic  evaluation  of 
candidate  MOTs  for  GOSIP  Conformance  Testing. 


7.  RECCX3NITI0N  OF  OTHER  CONFORMANCE  TESTING  ACTIVITIES 

NIST  seeks  to  provide  economical  and  adequate  conformance  testing. 
It  is  not  the  intent  of  NIST  to  duplicate  conformance  testing 
activities  where  those  activities  meet  Federal  requirements.  Thus, 
NIST  CSL  will  coordinate  with  other  organizations  to  harmonize 
conformance  testing  requirements. 

In  meeting  these  objectives,  NIST  CSL  will  consider  the  use  of 
existing  test  methods,  conformance  testing  procedures,  test 
laboratories  and  certification  systems. 

Possible  recognition  of  other  activities  include; 

1)  Foreign-based  test  laboratory  accreditation  and  services, 

2)  Test  method  administration  (maintenance  and  distribution 
systems) , 

3)  Conformance  testing  procedures, 

4)  Test  reports, 

5)  Certificates,  and 

6)  Test  method  research  and  development. 


NIST  may  use  any  of  the  following  methods  for  formally  recognizing 
the  conformance  testing  activities  of  other  organizations: 

1)  Contract, 

2)  Accreditation, 

3)  Memorandum  of  Understanding,  or 

4)  International  Standard. 

Any  of  the  above  methods  are  acceptable  if  they  do  not  conflict  with 
or  compromise  NIST*s  authority  in  carrying  out  its  responsibilities 
or  violate  Federal  regulations. 
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Unless  otherwise  approved  by  the  Director  of  NIST  CSL,  agreements 
concerning  conformance  testing  shall  not: 

1)  Grant  exclusive  rights  to  others  in  fulfilling  its 
responsibilities  in  the  areas  described  above. 

2)  Unilaterally  agree  to  adopt  a product  or  service  which  conflicts 
with,  or  that  does  not  allow  for  changes  to  meet,  NIST  CSL 
requirements . 
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GOSIP  CONFORMANCE  AND  INTEROPERATION  TESTING  AND  REGISTRATION 


PART  II:  TECHNICAL  CRITERIA  FOR  GOSIP  VERSION  1.0 


1. 


INTRODUCTION 


This  report  provides  the  overall  procedures  for  the  operation  of  the 
GOSIP  testing  and  registration  program,  and  specific  technical 
criteria  pertaining  to  GOSIP  protocols  and  profiles.  Consequently 
this  report  is  organized  into  separate  but  related  parts:  Part  I 
provides  the  overall  policy  and  operational  criteria  and  is 
applicable  to  all  future  versions  of  GOSIP;  This  part,  Part  II 
provides  the  technical  criteria  for  the  protocols  and  profiles 
specified  in  GOSIP  Version  1.0. 


1 . 1 Definitions 

Abstract  Test  Case:  A complete  and  independent  specification  of  the 
actions  required  to  achieve  a specific  test  purpose  (or  a specified 
combination  of  test  purposes) , defined  at  the  level  of  abstraction  of 
a particular  abstract  test  method.  It  may  include  a preamble  and 
postamble  to  ensure  starting  and  ending  in  a stable  state  (i.e.  an 
identifiable  stable  state  of  the  SUT  which  can  be  easily  reached  and 
maintained,  such  as  the  'idle'  state  or  the  'data  transfer'  state). 
This  specification  may  involve  one  or  more  consecutive  or  concurrent 
connections. 

Abstract  Test  Method:  The  description  of  how  an  lUT  is  to  be  tested, 
given  at  an  appropriate  level  of  abstraction  to  make  the  description 
independent  of  any  particular  implementation  of  testing  tools,  but 
with  enough  detail  to  enable  tests  to  be  specified  for  this  test 
method . 

Basic  Interconnection  Tests:  Limited  tests  of  an  Implementation 
Under  Test  (lUT)  to  determine  whether  or  not  there  is  sufficient 
conformance  to  the  relevant  protocol (s)  for  interconnection  to  be 
possible,  without  trying  to  perform  thorough  testing. 

Behavior  Tests:  Tests  to  determine  the  extent  to  which  the  dynamic 
conformance  requirements  are  met  by  the  lUT. 

Capability  Tests:  Tests  to  determine  the  capabilities  of  an  lUT. 
(Note,  this  involves  checking  all  mandatory  capabilities  and  those 
optional  ones  that  are  stated  in  the  Protocol  Implementation 
Conformance  Statement  (PICS)  as  supported,  but  not  checking  those 
optional  ones  which  are  stated  in  the  PICS  as  not  supported  by  the 
lUT. ) 

Conformance:  Fulfillment  by  a product  of  all  requirements  specified. 


Conformance  Testing:  Testing  the  extent  to  which  an  lUT  is  a 

conforming  implementation. 
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Coordinated  Test  Method:  An  external  test  method  for  which  a 
standardized  test  management  protocol  is  defined  as  the  test 
coordination  procedures,  enabling  the  control  and  observation  to  be 
specified  solely  in  terms  of  the  lower  tester  activity,  including  the 
control  and  observation  of  test  management  PDUs. 

Distributed  Test  Method:  An  external  test  method  in  which  there  is 
a PCO  at  the  layer  boundary  at  the  top  of  the  lUT. 

Dynamic  Conformance  Requirements:  All  those  requirements  and  options 
which  determine  what  observable  behavior  is  permitted  by  the  relevant 
OSI  standards  in  instances  of  communication. 

Embedded  Testing:  Testing  the  behavior  of  a single  layer  within  a 
multi-layer  lUT  without  accessing  the  layer  boundaries  for  that  layer 
within  the  lUT.  (This  is  contrasted  with  ‘exposed*  testing  in  which 
the  N-service  PCO  of  the  lUT  is  accessible  for  testing.) 

GOSIP  Product:  A product  which  implements  one  or  more  of  the  data 
communications  protocols  identified  in  GOSIP  and  meets  the 
requirements  specified  herein. 

Implementation  Under  Test  (lUT) : An  implementation  of  one  or  more 
OSI  protocols  in  an  adjacent  user/provider  relationship,  being  that 
part  of  a real  open  system  which  is  to  be  studied  by  testing. 

Means  of  Testing:  The  realization  of  an  abstract  test  method  as 
defined  in  the  OSI  Conformance  Testing  Methodology  and  Framework. 
This  realization  includes  the  test  system,  executable  test  suite, 
testing  support  tools  (hardware  and  software)  and  documentation 
(including  technical  test  procedures) . 

Multi-Layer  Testing:  Testing  the  behavior  of  a multi-layer  lUT  as  a 
whole,  rather  than  testing  it  layer  by  layer  (in  contrast  to  Single- 
Layer  Testing) . 

Out-of-band  Coordination:  A separate  communications  path  used  for 
test  coordination  procedures  which  may  be  realized  from  a lower-layer 
service  or  alternative  physical  media. 

Protocol  Conformance  Test  Report  (PCTR) : A document  written  at  the 
end  of  the  conformance  assessment  process,  giving  the  details  of  the 
testing  carried  out  for  a particular  protocol.  It  includes  the 
identification  of  the  abstract  test  cases  (if  these  exist)  for  which 
corresponding  executable  test  cases  were  run.  It  also  includes  the 
test  purpose (s)  and  verdict  for  each  test  case. 

Protocol  Implementation  Conformance  Statement  (PICS) : A statement 
made  by  the  supplier  of  an  OSI  implementation,  or  system,  stating 
which  capabilities  and  options  have  been  implemented,  for  a given  OSI 
protocol . 
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Protocol  Implementation  extra  Information  for  Testing  (PIXIT) : 

A statement  made  by  a supplier  or  implementor  of  an  lUT  which 
contains  or  references  all  of  the  information  (in  addition  to  that 
given  in  the  PICS)  related  to  the  lUT  and  its  testing  environment, 
which  will  enable  the  test  laboratory  to  run  an  appropriate  test 
suite  against  the  lUT. 

Remote  Test  Method:  An  external  test  method  in  which  there  is 
neither  a PCO  above  the  lUT  nor  a standardized  test  management 
protocol ; some  requirements  for  test  coordination  procedures  may  be 
implied  or  informally  expressed  in  the  abstract  test  suite  but  no 
assumption  is  made  regarding  their  feasibility  or  realization. 

Static  Conformance  Requirements:  Constraints  which  are  specified  in 
OSI  standards  to  facilitate  interworking  by  defining  the 
requirements  for  the  capabilities  of  an  implementation. 

System  Conformance  Test  Report  (SCTR) : A document  written  at  the  end 
of  the  conformance  assessment  process,  giving  the  overall  summary  of 
the  conformance  of  the  system  to  the  set  of  protocols  for  which 
conformance  testing  was  carried  out. 

System  Under  Test  (SUT)  : The  real  open  system  in  which  the  lUT 
resides . 

Test  Management  Protocol  (TMP) : A protocol  which  is  used  to 
implement  the  test  coordination  procedures  for  a particular  test 
suite. 

Transverse  Test  Method:  Used  for  testing  a relay  system  from  two 
subnetworks,  in  this  test  method  there  are  2 PCOs,  one  on  each 
subnetwork,  at  SAPs  external  from  the  N-relay. 

Verdict:  A statement  of  "Pass”,  "Fail",  or  "Inconclusive",  specified 
in  the  abstract  test  suite  concerning  conformance  of  an  lUT  with 
respect  to  a test  case  that  has  been  executed. 

1 . 2 Abbreviations 


AARE 

AARQ 

ACSE 

APDU 

ASN.l 

CLNP 

CLNPDU 

CLNS 

CONS 

CP 

CPA 

CPR 

CR 


A_Associate_Response  Service  Primitive 
A_Associate_Request  Service  Primitive 
Association  Control  Service  Elements 
ACSE  Protocol  Data  Unit 
Abstract  Syntax  Notation  One 
Connectionless  Network  Protocol 
Connectionless  Network  Protocol  Data  Unit 
Connectionless  Network  Service 
Connection  Oriented  Network  Service 
Presentation  Connect  PPDU 
Presentation  Accept  PPDU 
Presentation  Reject  PPDU 
Connect  Request  TPDU 
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ES  End  System 

FIPS  Federal  Information  Processing  Standard 

FPDU  File  Protocol  Data  Unit 

FTAM  File  Transfer  Access  and  Management 

GOSIP  Government  Open  Systems  Interconnection  Profile 

HDLC  High-level  Data  Link  Control 

IPMS  Interpersonal  Messaging  Service 

IS  Intermediate  System  (or  International  Standard) 

LAPB  Link  Access  Protocol  B 

LLC  Logical  Link  Control 

MTA  Message  Transfer  Agent 

CSL  Computer  Systems  Laboratory 

NVLAP  National  Voluntary  Laboratory  Accreditation  Program 

OSI  Open  Systems  Interconnection 

PI  PI  Protocol  for  Message  Transfer  Agents 

P2  P2  Protocol  for  Interpersonal  Messaging  Services 

PCO  Point  of  Control  and  Observation 

PCTR  Protocol  Conformance  Test  Report 

PPDU  Presentation  Protocol  Data  Unit 

QOS  Quality  of  Service 

RTS  Reliable  Transfer  Service 

SCTR  System  Conformance  Test  Report 

TTP  Transport  Test  Platform 

TPO  Transport  Protocol  Class  0 

TP4  Transport  Protocol  Class  4 
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1987. 

9 . Information  Processing  - Open  Systems  Interconnection  - 

Specification  of  Basic  Encoding  Rules  for  ASN.l,  ISO  8825,  1987. 
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CCITT 


1.  SDL,  Recommendation  Z.lOO,  1988,  International 
Telecommunications  Union,  Place  des  Nations,  CH  1211,  Geneva  20 
Switzerland. 

1.4  Organization  of  Part  II 

This  part  of  the  report  lists  the  3-  and  7-  layer  profiles  of  GOSIP 
version  1.0  and  describes  the  technical  criteria  for  Means  of  Testing 
necessary  for  each  GOSIP  protocol,  separated  into  Supporting  Protocol 
Criteria  (layers  1 through  6)  , and  Application  Protocol  Criteria 
(layer  7) . The  final  clause  provides  the  GOSIP  compliance  schedule 
for  version  1.0  protocols. 


1.5  Applicable  GOSIP  Profiles 

Below  is  a list  of  profiles  from  GOSIP  version  1.0  which  are  the 
basis  for  selection  of  substacks  for  testing. 

End  System  Profiles 

1 FTAM/ACSE/Presentation/Session/TP4/CLNP/LLCl/8802 . 3 

2 FTAM/ACSE/Presentation/Session/TP4/CLNP/LLCl/8802 . 4 

3 FTAM/ACSE/Presentation/Session/TP4/CLNP/LLCl/8802 . 5 

4 FTAM/ACSE/Presentation/Session/TP4/CLNP/X. 25/HDLC/V. 35 

5 FTAM/ACSE/Presentation/Session/TP4/CLNP/X.25/HDLC/RS232C 

6 FTAM/ACSE/Presentation/Session/TP4/X. 25/HDLC/V. 35 

7 FTAM/ACSE/Presentation/Session/TP4/X.25/HDLC/RS232C 

8 X. 400/Session/TP4/CLNP/LLCl/8802 . 3 

9 X. 400/Session/TP4/CLNP/LLCl/8802 . 4 

10  X. 400/Session/TP4/CLNP/LLCl/8802 . 5 

11  X. 400/Session/TP4/CLNP/X. 25/HDLC/V. 35 

12  X. 400/Session/TP4/CLNP/X. 25/HDLC/RS232C 

13  X. 4 00/Session/TP4/X. 25/HDLC/V. 35 

14  X. 400/Session/TP4/X. 25/HDLC/RS232C 

15  X. 400/Session/TP0/X. 25/HDLC/V. 35 

16  X. 400/Session/TP0/X. 25/HDLC/RS232C 

Seven  Laver  Relay  Profiles 

17  X. 400/Session/TP4/CLNP/LLCl/8802 . 3 

18  X. 400/Session/TP4/CLNP/LLCl/8802 . 4 

19  X. 400/Session/TP4/CLNP/LLCl/8802 . 5 

20  X . 4 00/Session/TP4/CLNP/X . 2 5/HDLC/V . 3 5 

2 1 X . 4 00/Session/TP4/CLNP/X . 2 5/HDLC/RS2  3 2C 

22  X. 400/Session/TP4/X. 25/HDLC/V. 35 

23  X.400/Session/TP4/X.25/HDLC/RS232C 

24  X. 400/Session/TP0/X. 25/HDLC/V. 35 

25  X.400/Session/TP0/X.25/HDLC/RS232C 


7 


Three  Laver  Relay  Profiles 


17  CLNP/LLCl/8802.3 

18  CLNP/LLCl/8802.4 

19  CLNP/LLCl/8802.5 

20  CLNP/X.25/HDLC/V.35 

21  CLNP/X.25/HDLC/RS232C 

The  possible  Transport  Test  Platforms  of  the  specified  GOSIP 
protocols  are  separately  identified  below:  the  first  seven  employ 
class  4 and  the  latter  two  employ  class  0. 

Transport  Platforms 

22  TP4/CLNP/LLC1/8802.3 

23  TP4/CLNP/LLC1/8802.4 

24  TP4/CLNP/LLC1/8802.5 

25  TP4/CLNP/X.25/HDLC/V.35 

26  TP4/CLNP/Xc25/HDLC/RS232C 

27  TP4/X.25/HDLC/V.35 

28  TP4/X.25/HDLC/RS232C 

29  TP0/X.25/HDLC/V.35 

30  TP0/X.25/HDLC/RS232C 

In  order  for  an  OSI  product  supplier  to  claim  7-layer  GOSIP  Version 
1.0  compliance  or  conformance  these  are  the  only  possible 
combinations.  Subject  to  Agency  requirements,  alternative  Link  and 
Physical  media  may  be  supplied.  In  such  cases  it  must  be  made  clear 
by  the  product  supplier  which  products,  or  aspects  of  a multi-layered 
product,  to  which  GOSIP  compliance  or  conformance  is  or  is  not 
applicable. 

2.  SUPPORTING  PROFILE  TESTING  CONSTRAINTS 

Profiles  for  the  supporting  layers  and  including  the  presentation 
layer  are  presented  in  this  clause  and  subclauses  identify  specific 
test  methods  and  their  associated  test  suite  constraints  for 
individual  protocols  and  for  profiles  within  GOSIP. 

Clause  3 provides  Application  profile  testing  constraints. 
Functional  requirements  for  testing  implementations  of  each  protocol 
are  specified  within  the  contexts  in  which  they  are  commonly 
packaged.  An  Acquisition  Authority  may  require  a different  packaging 
for  certain  GOSIP  protocol  combinations.  In  such  cases,  separate 
functional  requirements  for  conformance  test  systems  may  need  to  be 
developed  which  are  compatible  with  the  requirements  as  stated 
herein.  This  Clause  seeks  to  address  major  functional  requirements 
of  a means  of  testing  and  abstract  test  suite  for  each  protocol 
within  GOSIP. 

There  is  some  overlap  between  criteria  specified  in  Clauses  2 and  3 
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for  the  means  of  testing  and  test  suite  coverage.  This  overlap 
eliminates  forward  and  backward  references,  and  identifies  the 
different  roles  of  protocols  within  profiles  in  this  clause  and  the 
next.  This  self-contained  completeness  of  specifications  provides 
ease  of  reference  in  evaluation  of  the  means  of  testing  in  their 
different  protocol  testing  roles. 

The  abstract  test  methods  specified  in  defining  the  testing 
requirements  for  each  GOSIP  protocol  are  drawn  from  Part  2 of  the  OSI 
Conformance  Testing  Methodology  and  Framework  [ISO  1].  These 
definitions  are  duplicated  in  1.1  above. 

In  addition,  these  basic  concepts  are  constructive:  for  instance  the 
term  distributed  single-layer  embedded  testing  is  an  aggregation  of 
the  basic  methods  defined  above. 

2 . 1 General  Characteristics 

To  reduce  the  redundancy  in  this  Clause  and  the  next,  within  each 
protocol  clause,  the  common  characteristics  are  placed  here  in  this 
clause  and  referenced  in  each  subclause  entitled  "Characteristics  of 
the  Means  of  Testing" . 

Common  Characteristics  of  the  Means  of  Testing 

1)  The  capability  to  analyze  PICS  and  PIXIT  for  the  lUT  and  to 
select  and  parameterize  tests  to  be  run,  and  to  configure  the 
means  of  testing  for  communication  with  the  SUT. 

2)  Procedures  to  reconcile  PDU  and  test  data  with  the  test  purposes 
and  yield  a verdict  for  each  test  purpose. 

3)  The  capability  to  produce  Conformance  Test  Reports,  listing  test 
cases  executed  and  their  verdicts,  and  detailing  the  lUT 
behavior  in  cases  of  failure. 

4)  Capability  to  record  the  protocol  data  units  exchanged  with  the 
lUT  in  a conformance  log,  and  to  review  the  structure  and 
encoding  of  protocol  data  units  after  the  test  campaign  is 
complete. 

2 . 2 Physical 

FIPS  146  GOSIP  does  not  specify  any  particular  physical  layer 
protcols  or  characteristics.  Consequently,  no  particular  testing 
requirements  are  employed  in  this  testing  specification,  except 
insofar  as  physical  layer  media  shall  implicitly  provide 
communications  capability  when  testing  or  operating  link  through 
application  protocols  in  GOSIP  stacks. 
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2 . 3 Link 


The  link  layer  protocol  implementations  are  often  based  on  the 

combination  of  the  integrated  circuits  and  supplementary  controlling 
circuits.  The  conformance  of  a particular  implementation  and  the 
interoperability  of  the  implementation  with  other  implementation  are 
not  guaranteed  by  the  use  of  a 'good  chip*.  Conformance  testing  needs 
to  be  carried  out  for  every  implementation  regardless  of  its 

components  or  internal  design  in  order  to  ensure  that  the 

implementation  conforms  to  the  standard  and  therefore  has  the 

potential  for  interoperability  with  other  implementations. 

2.3.1  HDLC  (LAPB) 

2. 3. 1.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  HDLC  (LAPB)  DTEs  is  conducted  in  conjunction 
with  the  X.25  packet  layer  protocol  over  tested  physical  media.  The 
following  configurations  apply. 

X , 2 5/HDLC ( LAPB) /RS2  3 2C 
X . 2 5/HDLC ( LAPB ) / V . 3 5 

The  test  method  used  for  HDLC (LAPB)  testing  shall  be  the  remote 
single-layer  embedded  method. 

2. 3. 1.2  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  2.1  above. 

1)  The  capability  to  construct  HDLC  link  frames  and  send  them  to 
the  DTE  under  test  over  the  physical  medium. 

2)  The  capability  to  receive  and  decode  HDLC  link  frames  according 
to  IS  7776.  The  capability  to  validate  HDLC  frames  and  record 
the  results  in  a conformance  log. 

3)  The  capability  to  construct  valid  as  well  as  invalid  HDLC 
frames. 

4)  The  capability  to  monitor  and  to  initiate  HDLC  link  frame 
exchanges  with  the  SUT  and  to  record  the  results. 

2. 3. 1.3  Test  Suite  Coverage 

The  tests  used  shall  be  those  specified  in  the  X.25  DTE  conformance 
testing  - Data  Link  Layer  Test  Suite  [ISO  4]. 

2.3.2.  8802-2  (LLC)  Type  1 
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2. 3.2.1.  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  8802-2  (LLC)  type  1 operation  is  conducted 
over  tested  MAC  and  physical  layer  and  media.  The  following  station 
configurations  are  possible. 

8802-2/8802-3 

8802-2/8802-4 

8802-2/8802-5 


The  above  configuration  operates  in  the  contexts  of  Relay  Profiles 
or  Transport  Platform  Profiles. 

The  testing  method  for  the  8802-2  type  1 is  remote  embedded.  The 
means  of  testing  contains  a physical  and  MAC  layer  implementation 
necessary  to  exchange  LLC  frames  with  these  stations. 

2. 3. 2. 2.  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  testing,  the  means  of  testing  shall  support 
the  following  functions  in  addition  to  the  general  function  given  in 
clause  2.1  above. 

1.  Capability  to  construct  LLC  Type  1 TEST  and  XID  frames 
and  send  them  a peer  LLC  lUT  over  an  appropriate  LAN 
protocol  (8802-3,  8802-4  or  8802-5)  for  the  SUT. 

2.  Capability  to  receive  and  decode  LLC  type  1 frames. 

3.  Capability  to  construct  LLC  type  1 XID  and  TEST  frames 
with  valid  and  invalid  address  fields. 

2. 3. 2. 3.  Test  Suite  Coverage 

The  test  suite  shall  contain  tests  which  verify  the  following. 

1.  XID  request  and  response  frame  exchanges. 

2.  TEST  request  and  response  frame  exchanges. 

3.  Use  of  individual,  group  and  global  addresses. 

4 . Response  to  XID  and  TEST  request  frames  with  indivi- 
dual, group  and  global  addresses. 

In  addition,  by  utilizing  the  layer  4 protocol  PDU  exchanges  or  basic 
relay  PDU  transfers,  the  functionality  of  UI  frames  at  LLC  can  be 
inferred. 

2.3.3.  8802-3  (CSMA/CD)  MAC 

2. 3. 3.1.  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  8802-3  (CSMA/CD)  MAC  layer  operation  is 
conducted  over  tested  physical  layer  and  media.  8802-3  MAC  sublayer 
operates  over  various  8802-3  physical  layer  implementations.  The  LLC 
Type  1 TEST  frame  response  capability  in  SUTs  is  used  for  the  testing 
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of  8802-3  MAC  to  cause  the  data  frame  exchange  between  the  lUT  and 
the  Means  of  Testing. 

The  testing  method  for  the  8802-3  MAC  is  remote  embedded. 

2. 3. 3. 2.  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  testing,  the  means  of  testing  shall  support 
the  following  functions  in  addition  to  the  general  function  given  in 
clause  2.1  above. 

1.  Capability  to  construct  8802-3  MAC  frames  containing 
8802-2  LLC  type  1 Test  Request  and  send  them  to  a peer 
8802-3  MAC  lUT  over  an  appropriate  8802-3  physical 
layer  implementation  for  the  SUT. 

2.  Capability  to  receive  and  decode  8802-3  MAC  frames. 

3.  Capability  to  construct  valid  and  invalid  8802-3  MAC 
frames. 

4.  Capability  to  generate  traffic  on  the  medium  of  vari- 
able length. 

5.  Capability  to  generate  collision  with  8802-3  MAC 
frames  transmitted  by  the  lUT  at  a predetermined  point 
on  the  IUT*s  frame  transmission. 

6.  Capability  to  monitor  the  occurrences  of  collisions 
and  their  duration. 


2. 3. 3. 3.  Test  Suite  Coverage 

The  test  suite  shall  contain  tests  which  verify  the  following. 

1.  Valid  use  of,  and  response  to  different  types  of  MAC 
addresses . 

2.  Adherence  to  the  minimum  frame  size  with  the  valid  use 
of  PAD  along  with  the  correct  length  field  value. 

3.  8802-3  MAC  frame  construction. 

4.  Response  to  frames  with  valid  and  invalid  frame  length 
field  values. 

5.  Octet  alignment  procedure. 

6.  Response  to  frames  with  valid  and  invalid  FCS. 

7.  Collision  detection  capability  and  behavior  upon  the 
detection  of  collisions. 

2.3.4.  8802-4  (Token  Bus)  MAC 

2. 3. 4.1.  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  8802-4  (Token  Bus)  MAC  layer  operation  is 
conducted  over  tested  physical  layer  and  media.  The  8802-4  MAC 
sublayer  operates  over  various  8802-4  physical  layer  implementations. 
The  LLC  Type  1 TEST  frame  response  capability  in  SUTs  is  used  for  the 
testing  of  8802-4  MAC. 
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The  testing  method  for  the  8802-4  MAC  is  remote  embedded. 

2. 3.4.2.  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  testing,  the  means  of  testing  shall  support 
the  following  functions  in  addition  to  the  general  function  given  in 
clause  2.1  above. 

1.  Capability  to  construct  8802-4  MAC  frames  and  8802-4 
MAC  data  frame  containing  8802-2  LLC  type  1 Test 
Request  and  send  them  to  a peer  8802-4  MAC  lUT  over 
the  appropriate  8802-4  physical  layer  implementation. 

2.  Capability  to  construct  8802-4  frames  with  different 
addresses  to  emulate  frame  exchanges  among  multiple 
stations. 

3.  Capability  to  construct  and  send  valid  and  invalid 
8802-4  MAC  frames. 

4.  Capability  to  transmit  opportune  and  inopportune 
8802-4  MAC  frames. 

5.  Capability  to  validate  the  timing  of  the  lUT  frame 
transmissions . 

6.  Capability  to  receive  and  decode  8802-4  MAC  frames. 

2. 3. 4. 3.  Test  Suite  Coverage 

The  test  suite  shall  contain  tests  which  verify  the  following.  The 
verification  should  include  the  normal  and  fault  conditions  with 
correct  handling  of  priority  and  timing  requirements. 

1.  Claim  token  algorithm. 

2.  Token  passing  capabilities. 

3.  Ring  entry  and  exit  algorithms. 

4.  Ring  maintenance  mechanisms. 

5.  Ring  collapse  recovery  capability  including  the  handling 
of  duplicate  addresses. 

6.  Use  token  algorithm. 

7.  Handling  of  traffic  generated  by  other  stations, 
including  collisions. 

Test  suite  coverage  should  be  appropriate  for  the  requirements 
imposed  by  different  physical  layer  implementations  in  accordance 
with  the  8802-4  standard. 

2.3.5.  8802-5  (Token  Ring)  MAC 

2. 3. 5.1.  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  8802-5  (Token  Ring)  MAC  layer  operation  is 
conducted  over  tested  physical  layer  and  media.  The  8802-5  MAC 
sublayer  operates  over  various  8802-5  physical  layer  implementations. 
The  LLC  Type  1 TEST  frame  response  capability  in  SUTs  is  used  for  the 
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testing  of  8802-5  MAC. 

The  testing  method  for  the  8802-5  MAC  is  remote  embedded. 

2. 3. 5. 2.  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  testing,  the  means  of  testing  shall  support 
the  following  functions  in  addition  to  the  general  functions  given 
in  clause  2.1  above. 

1.  Capability  to  construct  8802-5  MAC  frames  and  8802-5 
MAC  data  frame  containing  8802-2  LLC  type  1 Test 
Request  and  send  them  to  a peer  8802-5  MAC  lUT  over 
the  appropriate  8802-5  physical  layer  implementation. 

2.  Capability  to  construct  8802-5  frames  with  different 
addresses  to  emulate  frame  exchanges  among  multiple 
stations. 

3.  Capability  to  construct  and  send  valid  and  invalid 
8802-5  MAC  frames. 

4.  Capability  to  transmit  opportune  and  inopportune 
8802-5  MAC  frames. 

5.  Capability  to  validate  the  timing  of  lUT  frame 
transmissions . 

6.  Capability  to  receive  and  decode  8802-5  MAC  frames. 

2. 3. 5. 3.  Test  Suite  Coverage 

The  test  suite  shall  contain  tests  which  verify  the  following. 

1.  Capability  to  construct  valid  MAC  control  and  data 
frames. 

2.  Standby  monitor. 

3.  Claim  token  capabilities  and  data  frame  transmission 
capability  with  adherence  to  the  priority  rules. 

4.  Transmission  window  observance  and  correct  token 
release  mechanism. 

5.  Token  passing  mechanism  under  different  priority 
relationship  to  other  stations  on  the  ring. 

6.  Frame  stripping. 

7.  Capability  to  receive  frames  and  check  for  their 
validity. 

8.  Error  handling  and  recovery  mechanisms  including 
beaconing  and  neighbor  notification. 

9.  Ring  entry  and  exit. 


2.4  Network 
2.4.1  X.25  (1980) 

So  long  as  attachment  to  X.25  (1980)  networks  is  required  by  an 

Acquisition  Authority,  the  test  method  and  test  suites  mandated  for 


14 


Department  of  Defense  use  shall  be  adopted  by  this  policy  (see  [NIST 

5])  . 

2.4.2  X.25  (1984) 

2.4.2. 1 Configuration  of  the  Means  of  Testing 

Conformance  testing  of  the  packet  protocol  of  X.25  (1984)  DTE  systems 
is  conducted  in  conjunction  with  HDLC(LAPB) , over  a tested  physical 
medium,  in  the  following  configurations. 

X . 2 5/HDLC ( LAPS ) /RS  2 3 2 C 
X . 2 5/HDLC ( LAPB ) / V . 3 5 

For  calls  initiated  by  the  means  of  testing  the  remote  single-layer 
method  shall  be  used.  For  calls  initiated  by  the  SUT,  either 
distributed  single  layer  or  distributed  layer  single  embedded  methods 
shall  be  used.  The  means  of  testing  shall  take  the  role  of  a DCE. 

2. 4. 2. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  functions 
specified  in  2.1  above. 

1)  The  capability  to  construct  X.25  packets  and  send  them  to  an 
attached  DTE  system. 

2)  The  capability  to  receive  and  decode  X.25  packets  according  to 
IS  8208.  The  capability  to  validate  X.25  packets  received  and 
record  the  results  in  a conformance  log. 

3)  The  capability  to  construct  invalid  as  well  as  valid  X.25 
packets . 

4)  The  capability  to  monitor  and  initiates  exchanges  of  X.25 
packets  between  the  means  of  testing  and  the  SUT  (inopportune  as 
well  as  normal) . 

2. 4. 2. 3 Test  Suite  Coverage 

The  tests  used  shall  be  those  specified  in  the  X.25  DTE  Conformance 
Testing  - Packet  Level  Conformance  Test  Suite  [ISO  5]. 

2.4.3  Connectionless  Network  Protocol  (CLNP) : End  Systems 
2. 4. 3.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  CLNP  End  Systems  is  conducted  in  conjunction 
with  the  transport  protocol,  class  4,  over  previously  tested 
subnetwork  services  of  the  following  configurations. 
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- X . 2 5/HDLC/RS  2 3 2 C ; 

- X.25/HDLC/V.35; 

- 8802.2/8802.3; 

- 8802.2/8802.4; 

- 8802. 2/8802. Sm- 
other network,  link  and  physical  media  as  sanctioned  by 
future  editions  of  GOSIP. 

The  preferred  method  of  realizing  CLNP  End  System  testing  is  by  use 
of  a transport  reference  entity  over  a CLNP  Test  implementation,  with 
coordination  provided  by  a test  management  protocol.  This  is  the 
coordinated  single-layer  embedded  method  of  testing. 

2. 4. 3. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  CLNPDUs  according  to  both  the  fully 
segmenting  and  the  non-segmenting  subsets,  and  send  them  to  a 
CLNP  End  System  Under  Test  over  any  supported  medium. 

2)  Capability  to  receive  and  decode  CLNPDUs  according  to  IS  8473. 
Capability  to  validate  CLNPDUs  received  and  record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  CLNPDUs. 

4)  Capability  to  monitor  and  to  initiate  CLNPDU  exchanges  with  the 
SUT  and  to  record  the  results. 

5)  Capability  to  control  and  coordinate  with  the  SUT  in  order  to 
induce  the  SUT  to  generate  specified  types  of  CLNPDUs.  This 
includes  control  and  coordination  with  the  transport  class  4 
entity  associated  with  the  CLNP  lUT. 

2. 4. 3. 3 Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  general 
behaviors  of  the  CLNP  lUT. 

Responses  to  valid  data  and  Error  CLNPDUs. 

Ability  to  generate  valid  data  and  Error  CLNPDUs. 

Responses  to  invalid  data  and  Error  CLNPDUs. 

Responses  to  inopportune  data  and  Error  CLNPDUs. 

In  the  case  of  a connection  oriented  subnetwork,  response  to 
loss,  reset,  and  restart  of  the  network  connection (s) . 

Specific  functions  for  which  tests  shall  exist  include  the  following; 

PDU  composition; 

PDU  decomposition; 
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Header  format  analysis; 

PDU  lifetime  control; 

Route  PDU; 

- Forward  PDU ; 

- Segment  PDU ; 

- Reassemble  PDU; 

Discard  PDU ; 

Error  reporting; 

Header  error  detection; 

Complete  route  recording  (decoding  on  receipt) ; 

- Partial  route  recording  (decoding  on  receipt) ; 

Priority; 

QOS  maintenance; 

Padding. 

2.4.4  Connectionless  Network  Protocol:  Intermediate  Systems 

For  the  purposes  of  GOSIP  Version  1.0,  Intermediate  System  testing 
shall  include  IS  8473  only.  The  ES-IS  routing  protocol,  IS  9542  is 
not  a requirement  until  GOSIP  Version  2.0.  Consequently  no  testing 
requirements  for  ES-IS  are  specified  here. 

2.4.4. 1 Configuration  of  the  Means  of  Testing 

Testing  for  Intermediate  Systems  shall  be  conducted  by  interposing 
the  System  Under  Test  between  a pair  of  testers  which  incorporate 
CLNP  End  System  implementations.  Coordination  shall  be  by  Test 
Management  Protocol  between  the  pair  of  testers,  which  may  operate 
directly  over  the  CLNP  protocol,  or  over  transport  class  4.  This  is 
the  transverse  method  of  testing.  This  configuration  holds  for  each 
subnetwork  pair  supported  by  the  SUT.  The  subnetwork  profiles  are 
drawn  from  the  following; 

- X . 2 5/HDLC/RS  2 3 2 C ; 

- X.25/HDLC/V.35; 

- 8802.2/8802.3; 

- 8802.2/8802.4; 

- 8802.2/8802.5; 

- Other  network,  link  and  physical  media  as  sanctioned  by 
future  editions  of  GOSIP. 

2. 4. 4. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  CLNPDUs  according  to  both  the  fully 
segmenting  and  the  non-segmenting  subsets,  and  send  them  to  an 
CLNP  End  System  Under  Test  over  any  supported  medium. 

2)  Capability  to  receive  and  decode  CLNPDUs  according  to  IS  8473. 
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Capability  to  validate  received  CLNPDUs  and  record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  CLNPDUs. 

4)  Capability  to  monitor  and  to  initiate  CLNPDU  exchanges  with  the 
SUT  and  to  record  the  results. 

5)  Capability  to  control  and  coordinate  with  a second  means  of 
testing  to  generate  specified  types  of  CLNPDU.  All  CLNPDUs 
passing  between  the  pair  of  testers  are  routed  through  the  SUT. 

2.4.4. 3 Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  general 
behaviors  of  the  CLNP  lUT. 

Responses  to  valid  data  and  Error  CLNPDUs. 

- Ability  to  generate  valid  data  and  Error  CLNPDUs. 

- Responses  to  invalid  data  and  Error  CLNPDUs. 

- Responses  to  inopportune  data  and  Error  CLNPDUs. 

In  the  case  of  a connection  oriented  subnetwork,  response  to 
loss,  reset,  and  restart  of  the  network  connection (s) . 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

PDU  composition; 

PDU  decomposition; 

Header  format  analysis; 

PDU  lifetime  control; 

Route  PDU ; 

Forward  PDU ; 

Segment  PDU; 

Reassemble  PDU; 

Discard  PDU; 

Error  reporting; 

Header  error  detection; 

Complete  route  recording  (decoding  on  receipt) ; 

Partial  route  recording  (decoding  on  receipt) ; 

Priority; 

QOS  maintenance; 

Padding; 

Tests  for  support  of  CLNPDU  segmentation  by  the  Intermediate 
System; 

Tests  for  behavior  of  the  Intermediate  System  under  lifetime 
expiration; 

Congestion  notification  tests. 

2 . 5 Transport 

The  classes  of  transport  sanctioned  by  GOSIP  are  class  4 and  class 
0.  In  this  clause,  the  requirement  of  single-layer  "exposed”  testing 
methods  only  is  discussed. 
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2.5.1  Class  4 


2. 5. 1.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  transport  class  4 shall  be  conducted  in 
conjunction  with,  or  after,  testing  of  CLNP.  Alternatively,  Class  4 
may  be  operated  over  X.25  Connection  Oriented  Network  Service. 
Coordination  is  by  use  of  a Test  Management  Protocol  operating  over 
transport.  This  is  the  coordinated  single  layer  method  of  testing. 
Network  profiles  for  support  of  Class  4 may  be. 

- X . 2 5/HDLC/RS  2 3 2 C ; 

- X.25/HDLC/V.35; 

- CLNP/X . 2 5/HDLC/RS2  3 2C ; 

- CLNP/X . 2 5/HDLC/V .35; 

- CLNP/8802 . 2/8802 . 3 ; 

- CLNP/8802 . 2/8802 . 4 ; 

- CLNP/8802 . 2/8802 . 5 ; 

Other  network,  link  and  physical  media  as  sanctioned  by 
future  editions  of  GOSIP. 

2.5. 1.2  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  TPDUs  according  to  the  class  4 protocol 
and  send  them  to  a peer  transport  entity  under  test,  over  an 
CLNP  service  or  X.25  network-layer  service. 

2)  Capability  to  receive  and  decode  TPDUs  and  classify  them 
according  to  IS  8073.  Capability  to  validate  received  TPDUs  and 
record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  TPDUs. 

4)  Capability  to  monitor  and  to  initiate  TPDU  exchanges  with  the 
SUT  (inopportune  as  well  as  normal)  and  to  record  the  results. 

5)  Capability  to  support  multiple  concurrent  transport  connections; 
ability  to  multiplex  more  than  one  transport  connection  over  a 
single  X.25  connection;  ability  to  split  a transport  connection 
across  more  than  one  X.25  connection. 

6)  Capability  to  control  and  to  coordinate  with  the  SUT  in  order 
to  induce  the  SUT  to  generate  specified  types  of  TPDU.  This 
includes  control  and  coordination  using  specific  test 
coordination  procedures,  which  may  be  in  the  form  of  a Test 
Management  Protocol,  at  the  transport  service  or  in  conjunction 
with  transport  protocol  data. 
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2.5. 1.3  Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  general 
behaviors  of  the  class  4 lUT. 

- Negotiate  during  connection  establishment,  and  support 
throughout  the  connection,  those  options  identified  within 
GOSIP  and  the  Stable  Implementation  Agreements  [NIST  2,  NIST 

9]. 

Respond  correctly  to  improperly  negotiated  options.  Respond 
correctly  to  options  negotiated  properly  but  violated  during 
subsequent  conduct  of  the  connection. 

Recovery  from  inopportune  TPDUs,  in  all  states. 

Recovery  from  invalid  TPDUs. 

Specific  functions  for  which  tests  shall  exist  include  the  following i 

Assignment  to  network  connection  (for  TP4  over  CONS) ; 

TPDU  transfer; 

Segmenting  and  Reassembling; 

Concatenation  and  Separation; 

Connection  establishment,  including:  initiating  a valid 

class  4 CR  TPDU  and  accepting  a valid  class  4 CC  TPDU  in 
response;  responding  to  a valid  class  4 CR  TPDU  with  a valid 
class  4 CC  TPDU; 

Connection  refusal ; 

Explicit  normal  release; 

- Association  of  TPDUs  with  transport  connection; 

DT  TPDU  numbering; 

Expedited  data  transfer  (network  normal  variant) ; 

Retention  until  acknowledgement  of  TPDUs; 

- Multiplexing  and  demultiplexing  (multiple  transport 
connections  over  a single  network  connection,  or  multiple 
transport  connections  over  a CLNS) ; 

Use  of  explicit  flow  control; 

- Use  or  non-use  of  checksum; 

Frozen  references; 

Retransmission  on  timeout; 

Resequencing; 

Inactivity  control ; 

Treatment  of  protocol  errors; 

Splitting  and  recombining. 


2.5.2  Class  0 

2. 5. 2.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  transport  class  0 shall  be  conducted  in 
conjunction  with,  or  after,  testing  of  X.25.  Coordination  is  by  use 
of  a Test  Management  Protocol  operating  over  transport.  This  is  the 
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coordinated  single  layer  method  of  testing.  Network  profiles  are  as 
follows. 


- X.25/HDLC/RS232C; 

- X.25/HDLC/V.35. 

2. 5. 2. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met  the  means  of  testing 

shall  support  the  following  functions  in  addition  to  the  general 

functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  TPDUs  according  to  the  class  0 protocol 
and  send  them  to  a peer  transport  entity  under  test,  over  an 
X.25  network-layer  service. 

2)  Capability  to  receive  and  decode  TPDUs  and  classify  them 
according  to  IS  8073.  Capability  to  validate  received  TPDUs  and 
record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  TPDUs. 

4)  Capability  to  monitor  and  to  initiate  TPDU  exchanges  with  the 
SUT  (inopportune  as  well  as  normal)  and  to  record  the  results. 

5)  Capability  to  control  and  to  coordinate  with  the  SUT  in  order 
to  induce  the  SUT  to  generate  specified  types  of  TPDU.  This 
includes  control  and  coordination  using  specific  test 
coordination  procedures,  which  may  be  in  the  form  of  a Test 
Management  Protocol,  at  the  transport  service  or  in  conjunction 
with  transport  protocol  data. 

6)  Capability  to  manage  successive  underlying  X.25  connections  and 
to  arbitrarily  reset,  restart  or  disconnect. 

2. 5. 2. 3 Test  Suite  Coverage 


The  test  suite  shall  contain  tests  for  the  following  general 
behaviors  of  the  class  0 lUT. 


Negotiate  during  connection  establishment,  and  support 
throughout  the  connection,  the  options  of  the  session 
protocol  identified  within  GOSIP  and  the  Stable 
Implementation  Agreements  [NIST  2,  NIST  9]. 

Respond  correctly  to  improperly  negotiated  options.  Respond 
correctly  to  options  negotiated  properly  but  violated  during 
subsequent  PDU  exchanges. 

Recovery  from  inopportune  TPDUs,  in  all  states. 

Recovery  from  invalid  TPDUs. 

Recovery  from  loss,  reset  or  restart  of  the  X.25  connection. 


Specific  functions  for  which  tests  shall  exist  include  the  following: 
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Assignment  to  network  connection; 

TPDU  transfer; 

Segmenting  and  reassembly; 

Connection  establishment,  including:  initiating  a valid 

class  0 CR  TPDU  and  accepting  a valid  class  0 CC  TPDU  in 
response;  responding  to  a valid  class  0 CR  TPDU  with  a valid 
class  0 CC  TPDU; 

Connection  refusal ; 

Implicit  normal  release; 

Error  release,  including  response  to  loss,  reset  or  restart 
of  the  network  connection; 

Association  of  TPDUs  with  transport  connections; 

Non-use  of  explicit  flow  control; 

Non-use  of  checksum; 

Treatment  of  protocol  errors. 

2 . 6 Session 

GOSIP  1.0  includes  both  FTAM  and  MHS  applications  which  use  different 
functional  subsets  of  the  session  protocol.  A supplier  may  package 
the  session  functionality  in  different  ways,  according  to  the 
application  supported,  or  may  choose  to  provide  an  independent 
session  service.  The  test  methods  described  in  this  clause  shall  be 
selected  according  to  the  configuration  of  the  supplier’s  product 
tested. 

If  a session  product  is  tested  by  the  single-layer  method,  then 
comprehensive  retesting  is  not  necessary  for  each  different 
application  which  it  supports.  If  a product  is  tested  by  one  of  the 
embedded  methods,  then  retesting  is  required  for  each  different 
application  and  mode  of  use.  Specifically,  the  different  embedded 
methods  of  testing  do  not  substitute  for  each  other,  but  single- 
layer "exposed"  testing  subsumes  the  other  methods. 


2 .6.1  Exposed  Session  Service 

All  Tested  Transport  Platforms  are  applicable. 


2. 6. 1.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  session  may  be  conducted  independently,  over 
a previously  tested  GOSIP  transport  platform.  An  exposed  session 
means  of  testing  shall  be  capable  of  testing  all  functional  units 
of  the  session  protocol,  even  though  any  specific  implementation 
might  support  only  one  or  more  of  the  major  subsets.  Coordination 
between  tester  and  lUT  may  be  by  agreed  test  coordination  procedures, 
or  by  an  explicit  Test  Management  Protocol.  This  uses  the 
coordinated  single-layer,  or  the  distributed  single-layer,  method  of 
testing. 
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2. 6. 1.2  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  SPDUs  and  send  them  to  a peer  session 
entity  under  test  over  a transport-layer  service. 

2)  Capability  to  receive  and  decode  SPDUs  and  classify  them 
according  to  IS  8327.  Capability  to  validate  SPDUs  received  and 
record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  SPDUs. 

4)  Capability  to  monitor  and  initiate  SPDU  exchanges  with  the  SUT 
(inopportune  as  well  as  normal)  and  to  record  the  results. 

5)  Capability  to  control  and  to  coordinate  with  the  SUT  in  order 
to  induce  the  SUT  to  generate  specified  types  of  SPDU.  This 
includes  control  and  coordination  using  specific  test 
coordination  procedures,  which  may  be  in  the  form  of  a Test 
Management  Protocol,  at  the  session  service  or  in  conjunction 
with  session  protocol  data. 

2. 6. 1.3  Test  Suite  Coverage 

Negotiate  and  support  throughout  the  connection  the 
functional  units  and  options  of  the  session  protocol  which 
are  identified  within  GOSIP  and  the  Stable  Implementation 
Agreements  [NIST  2,  NIST  9]. 

Respond  correctly  to  improperly  negotiated  options.  Respond 
correctly  to  options  negotiated  properly  but  violated  during 
subsequent  PDU  exchanges. 

Recovery  from  Inopportune  SPDUs  in  all  states. 

Recovery  from  Invalid  SPDUs,  where  specified  by  IS  8327. 
Response  to  valid  and  invalid  SPDU  concatenation  sequences. 
Recovery  from  different  uses  of  the  underlying  transport 
connection,  including  spurious  disconnection,  and  use  of 
expedited  service  when  they  are  not  requested. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

Connection  establishment,  including:  initiating  a valid 

connect  SPDU  and  accepting  a response  of  an  accept  SPDU  or 
refuse  SPDU;  accepting  a valid  connect  SPDU  and  responding 
with  an  accept  SPDU  or  refuse  SPDU,  as  appropriate. 

Normal  data  transfer,  half-duplex  and  duplex; 

Token  management ; 

Exception  reporting; 

Typed  data  transfer; 
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Minor  synchronization  point; 

Major  synchronization  point; 

Resynchronize; 

- Expedited  data  transfer; 

- Activity  management; 

Capability  data  exchange; 

Orderly  connection  release; 

Disorderly  connection  release. 

2.6.2  Remote  Single-layer  Embedded  Session  Testing  for  FTAM 

2. 6.2.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  session  may  be  conducted  in  conjunction  with 
FTAM,  ACSE  and  presentation,  over  a tested  GOSIP  transport  platform. 
An  embedded  means  of  testing  for  the  session  protocol  configured  for 
FTAM  support  shall  be  capable  of  testing  Kernel,  Duplex,  Minor 
Synchronization  and  Resynchronize  functional  units.  There  are  no 
explicit  test  coordination  requirements  for  the  remote  single-layer 
embedded  method  of  testing.  All  Tested  Transport  Platforms  are 
applicable. 

2. 6. 2. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  SPDUs  and  send  them  to  a peer  session 
entity  under  test  over  a transport-layer  service. 

2)  Capability  to  receive  and  decode  SPDUs  and  classify  them 
according  to  IS  8327.  Capability  to  validate  SPDUs  received  and 
record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  SPDUs. 

4)  Capability  to  monitor  and  initiate  SPDU  exchanges  with  the  SUT 
(inopportune  as  well  as  normal)  and  to  record  the  results. 


2. 6. 2. 3  Test  Suite  Coverage 

Negotiate  and  support  throughout  the  connection  the 
functional  units  and  options  of  session  which  are  identified 
within  GOSIP  and  the  Stable  Implementation  Agreements  [NIST 
2,  NIST  9] . 

Respond  correctly  to  improperly  negotiated  options.  Respond 
correctly  to  options  negotiated  properly  but  violated  during 
subsequent  PDU  exchanges. 

Recovery  from  Inopportune  SPDUs  in  all  states. 
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Recovery  from  Invalid  SPDUs,  where  specified  by  IS  8327. 
Response  to  valid  and  invalid  SPDU  concatenation  sequences. 
Recovery  from  different  uses  of  the  underlying  transport 
connection,  including  spurious  disconnection,  and  use  of 
expedited  when  not  requested. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

Connection  establishment,  including:  accepting  a valid 

connect  SPDU  and  responding  with  accept  SPDU  or  refuse  SPDU. 
as  appropriate; 

Normal  data  transfer,  and  duplex; 

Minor  synchronization  point; 

Resynchronize; 

Orderly  connection  release; 

Disorderly  connection  release. 


2.6.3  Distributed  Single-layer  Embedded  Session  Testing  for  FTAM 

2. 6. 3.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  session  may  be  conducted  in  conjunction  with 
FTAM,  ACSE  and  presentation,  over  a tested  GOSIP  transport  platform. 
An  embedded  means  of  testing  for  the  session  protocol  configured  for 
FTAM  support  shall  be  capable  of  testing  Kernel,  Duplex,  Minor 
Synchronization  and  Resynchronize  functional  units.  Test 

coordination  is  by  agreed  procedures  between  Test  laboratory  and 

product  supplier.  This  is  the  distributed  single-layer  embedded 
method  of  testing.  All  Tested  Transport  Platforms  are  applicable. 

2. 6. 3. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  SPDUs  and  send  them  to  a peer  session 
entity  under  test  over  a transport-layer  service. 

2)  Capability  to  receive  and  decode  SPDUs  and  classify  them 

according  to  IS  8327.  Capability  to  validate  SPDUs  received  and 
record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  SPDUs. 

4)  Capability  to  monitor  and  initiate  SPDU  exchanges  with  the  SUT 

(inopportune  as  well  as  normal)  and  to  record  the  results. 

5)  Capability  to  control  and  to  coordinate  with  the  SUT  in  order 
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to  induce  the  SUT  to  generate  specified  types  of  SPDU.  This 
control  and  coordination  of  an  embedded  session  entity  is 
effected  by  manipulation  of  higher  layer  PDUs  which  drive  the 
session  service. 

2. 6. 3. 3 Test  Suite  Coverage 

Negotiate  and  support  throughout  the  connection  the 
functional  units  and  options  of  the  session  protocol  which 
are  identified  within  GOSIP  and  the  Stable  Implementation 
Agreements  [NIST  2,  NIST  9]. 

Respond  correctly  to  improperly  negotiated  options.  Respond 
correctly  to  options  negotiated  properly  but  violated  during 
subsequent  conduct  of  the  connection. 

Recovery  from  Inopportune  SPDUs  in  all  states. 

Recovery  from  Invalid  SPDUs,  where  specified  by  IS  8327. 
Response  to  valid  and  invalid  SPDU  concatenation  sequences. 
Recovery  from  different  uses  of  the  underlying  transport 
connection,  including  spurious  disconnection,  and  use  of 
expedited  when  not  requested. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

- Connection  establishment,  including:  initiating  a valid 

connect  SPDU  and  accepting  a response  of  accept  SPDU  or 
refuse  SPDU,  as  appropriate; 

Normal  data  transfer,  and  duplex; 

Minor  synchronization  point; 

Resynchronize; 

Orderly  connection  release; 

Disorderly  connection  release. 

2.6.4  Distributed  Single-layer  Embedded  Session  Testing  for  MHS 

2.6.4. 1 Configuration  of  the  Means  of  Testing 

Conformance  testing  of  session  may  be  conducted  in  conjunction  with 
the  X.400  series  of  protocols  (MHS  - P2,  PI  and  RTS),  over  a tested 
GOSIP  transport  platform.  Any  embedded  means  of  testing  a session 
implementation  configured  for  MHS  support  shall  be  capable  of 
testing:  Kernel,  Exceptions,  Activity  Management,  Half -duplex,  and 

Minor  Synchronization  functional  units.  Test  coordination  is  by 
agreed  procedures  between  the  test  laboratory  and  product  supplier. 
This  is  the  distributed  single-layer  embedded  method  of  testing.  All 
Tested  Transport  Platforms  are  applicable. 

2. 6.4.2  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 
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1)  Capability  to  construct  SPDUs  and  send  them  to  a peer  session 
entity  under  test  over  a transport-layer  service. 

2)  Capability  to  receive  and  decode  SPDUs  and  classify  them 
according  to  IS  8327.  Capability  to  validate  SPDUs  received  and 
record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  SPDUs. 

4)  Capability  to  monitor  and  initiate  SPDU  exchanges  with  the 
SUT ( inopportune  as  well  as  normal)  and  to  record  the  results. 

5)  Capability  to  control  and  to  coordinate  with  the  SUT  in  order 
to  induce  the  SUT  to  generate  specified  types  of  SPDU.  This 
control  and  coordination  of  an  embedded  session  entity  is 
effected  by  manipulation  of  higher-layer  PDUs  which  drive  the 
session  service. 


2. 6.4. 3 Test  Suite  Coverage 

- Negotiate  and  support  throughout  the  connection  the 
functional  units  and  options  of  the  session  protocol  which 
are  identified  within  GOSIP  and  the  Stable  Implementation 
Agreements  [NIST  2,  NIST  9]. 

Respond  correctly  to  improperly  negotiated  options.  Respond 
correctly  to  options  negotiated  properly  but  violated  during 
subsequent  conduct  of  the  connection. 

Recovery  from  Inopportune  SPDUs  in  all  states. 

Recovery  from  Invalid  SPDUs,  where  specified  by  IS  8327. 
Response  to  valid  and  invalid  SPDU  concatenation  sequences. 

- Recovery  from  different  uses  of  the  underlying  transport 
connection,  including  spurious  disconnection,  and  use  of 
expedited  when  not  requested. 

Specific  functions  for  which  tests  shall  exist  include  the  following; 

Connection  establishment,  including; 

accepting  a valid  connect  SPDU  and  responding  with  accept 
SPDU  or  refuse  SPDU,  as  appropriate; 

initiating  a valid  connect  SPDU  and  responding  with  accept 
SPDU  or  refuse  SPDU  as  appropriate; 

Normal  data  transfer,  half-duplex; 

Minor  synchronization  point; 

Orderly  connection  release; 

Disorderly  connection  release; 

Exception  management ; 

Activity  management; 

Token  management . 

2 . 7 Presentation 
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2.7.1  Remote  Single-layer  Embedded  Presentation  Testing  for  FTAM 

2.7. 1.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  presentation  may  be  conducted  in  conjunction 
with  FTAM,  ACSE  and  session,  over  a tested  GOSIP  transport  platform. 
An  embedded  means  of  testing  for  the  presentation  protocol  configured 
for  FTAM  support  shall  be  capable  of  testing  the  presentation  kernel 
functionality,  and  in  addition  provide  transparent  access  to  the 
session  kernel,  duplex,  minor  synchronize,  and  resynchronize 
functional  units.  There  are  no  explicit  test  coordination 
requirements  for  the  remote  single-layer  embedded  method  of  testing. 
All  Tested  Transport  Platforms  (TTPs)  are  applicable.  Applicable 
profiles  are  as  follows. 

FTAM/ACSE/Presentation/Session/TTPs 


2. 7 el. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  PPDUs  and  send  them  to  a peer 
presentation  entity  under  test  over  a session-layer  service. 

2)  Capability  to  receive  and  decode  PPDUs  and  classify  them 
according  to  IS  8823.  Capability  to  validate  PPDUs  received  and 
record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  PPDUs. 

4)  Capability  to  monitor  and  initiate  PPDU  exchanges  with  the 
SUT ( inopportune  as  well  as  normal)  and  to  record  the  results. 

2. 7. 1.3  Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  general 
behaviors  of  the  presentation  lUT. 

- Negotiate  and  support  throughout  the  connection  the 
functional  units  and  options  of  presentation  which  are  within 
GOSIP  and  the  Stable  Implementors  Agreements  [NIST  2,  NIST 

9]- 

Respond  correctly  to  improperly  negotiated  options.  Respond 
correctly  to  options  negotiated  properly  but  violated  during 
subsequent  conduct  of  the  connection. 

- Recovery  from  Inopportune  PPDUs  in  all  states. 

Recovery  from  Invalid  PPDUs,  where  specified  by  IS  8823. 
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- Recovery  from  different  uses  of  the  underlying  session 
connection. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

- Accepting  a valid  CP  PPDU  and  responding  with  CPA  PPDU  or  CPR 
PPDU,  as  appropriate; 

- Presentation  kernel  tests  including  the  above  connection 
establishment  tests,  plus  transfer  of  normal  data  and  release 
of  a presentation  connection; 

Selection  of  transfer  syntax; 

Selection  of  abstract  syntax,  including  ACSE. 

Transparent  use  of  all  required  session  services  including: 

Normal  data  transfer,  half-duplex  and  duplex; 

- Minor  synchronization  point; 

Resynchronize; 

Orderly  connection  release; 

Disorderly  connection  release. 

2.7.2  Distributed  Single-layer  Embedded  Presentation  Testing  for 
FTAM 

2.7.2. 1 Configuration  of  the  Means  of  Testing 

Conformance  testing  of  presentation  may  be  conducted  in  conjunction 
with  FTAM,  ACSE  and  session,  over  a tested  GOSIP  transport  platform. 
An  embedded  means  of  testing  for  the  presentation  protocol  configured 
for  FTAM  support  shall  be  capable  of  testing  the  presentation  kernel 
functionality,  and  in  addition  provide  transparent  access  to  the 
session  kernel,  duplex,  minor  synchronize,  and  resynchronize 
functional  units.  Test  coordination  is  by  agreed  procedures  between 
the  test  laboratory  and  the  product  supplier.  This  uses  the 
distributed  single-layer  embedded  method  of  testing.  All  Tested 
Transport  Platforms  (TTPs)  are  applicable. 

Applicable  profiles  are: 

FTAM/ACSE/Presentation/Session/TTPs . 


2. 7. 2. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  PPDUs  and  send  them  to  a peer 
presentation  entity  under  test  over  a session-layer  service. 

2)  Capability  to  receive  and  decode  PPDUs  and  classify  them 
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according  to  IS  8823.  Capability  to  validate  PPDUs  received  and 
record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  PPDUs. 

4)  Capability  to  monitor  and  initiate  PPDU  exchanges  with  the  SUT 
(inopportune  as  well  as  normal)  and  to  record  the  results. 

5)  Capability  to  control  and  to  coordinate  with  the  SUT  in  order 
to  induce  the  SUT  to  generate  specified  types  of  PPDU.  This 
control  and  coordination  of  an  embedded  presentation  entity  is 
effected  by  manipulation  of  higher  layer  PDUs  which  drive  the 
presentation  service. 

2. 7. 2. 3 Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  general 
behaviors  of  the  presentation  lUT. 

Negotiate  and  support  throughout  the  connection  the 
functional  units  and  options  of  presentation  which  are 
identified  within  the  GOSIP  and  the  Stable  Implementation 
Agreements  [NIST  2,  NIST  9]. 

- Respond  correctly  to  improperly  negotiated  options.  Respond 
correctly  to  options  negotiated  properly  but  violated  during 
subsequent  PDU  exchanges. 

- Recovery  from  Inopportune  PPDUs  in  all  states. 

Recovery  from  Invalid  PPDUs,  where  specified  by  IS  8823. 
Recovery  from  different  uses  of  the  underlying  session 
connection. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

- Initiating  a valid  CP  PPDU  and  accepting  CPA  PPDU  or  CPR 
PPDU,  in  response; 

Presentation  kernel  tests  including  the  above  connection 
establishment  tests,  plus  transfer  of  normal  data  and  release 
of  a presentation  connection; 

Selection  of  transfer  syntax; 

Selection  of  abstract  syntax,  including  ACSE. 

Transparent  use  of  all  required  session  services  including: 

Normal  data  transfer,  half-duplex  and  full  duplex. 

Minor  synchronization  point. 

Resynchronize, 

Orderly  connection  release,  and 
Disorderly  connection  release. 
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2.8  ASN.l 


Tests  for  encoding  and  decoding  of  ASN.l  transfer  syntax  are 
incorporated  in  the  test  suites  for  the  application  protocols,  where 
appropriate. 


3.  APPLICATION  PROFILE  TESTING  CONSTRAINTS 

Application  protocols  are  treated  in  a separate  clause  from 
supporting  profiles  because  of  their  extent  and  diversity.  The 
complete  set  of  7-layer  profile  combinations,  including  both 
Application  and  support  profiles,  is  given  in  clause  1.5. 

3 . 1 ACSE 

3.1.1  Remote  Single-Layer  Embedded  ACSE  Testing  for  FTAM  Responder 

3. 1.1.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  ACSE  responders  may  be  conducted  in 
conjunction  with  FTAM,  presentation  and  ASN.l  over  a tested  GOSIP 
session  platform,  or  else  in  conjunction  with  FTAM,  presentation, 
ASN.l  and  session  over  a tested  GOSIP  transport  platform.  Test 
coordination  is  implicit,  since  the  only  point  of  control  and 
observation  is  remote  using  the  transport  (or  session)  service.  This 
uses  the  remote  single-layer  embedded  method  of  testing.  All  Tested 
Transport  Platforms  (TTPs)  are  applicable.  Applicable  profiles  are: 

- FTAM/ACSE/Presentation/Session/TTPs . 

3. 1.1.2  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  APDUs  and  send  them  to  a peer  ACSE 
entity  under  test  over  a presentation-layer  service. 

2)  Capability  to  receive  and  decode  APDUs  and  classify  them 
according  to  IS  8650.  Capability  to  validate  received  APDUs  and 
record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  APDUs. 

4)  Capability  to  monitor  and  initiate  APDU  exchanges  with  the  SUT 
(inopportune  as  well  as  normally)  and  to  record  the  results. 

3 . 1 . 1 . 3 Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  general 


31 


behaviors  of  the  ACSE  lUT. 


- Negotiate  and  support  throughout  the  connection  the 
functional  units  and  options  of  ACSE  which  are  identified 
within  the  GOSIP  and  the  Stable  Implementation  Agreements 
[NIST  2,  NIST  9]. 

Respond  correctly  to  improperly  negotiated  options.  Respond 
correctly  to  options  negotiated  properly  but  violated  during 
subsequent  conduct  of  the  connection. 

Recovery  from  inopportune  APDUs  in  all  states. 

Recovery  from  invalid  APDUs,  where  specified. 

- Recovery  from  different  uses  of  the  underlying  presentation 
connection. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

“ Accepting  a valid  AARQ  APDU  and  responding  with  an  AARE  APDU? 
Association  release  and  abort  tests. 

Transparent  use  of  required  presentation  and  session  services 
including: 

Normal  data  transfer,  and  duplex, 

Minor  synchronization  point. 

Resynchronize , 

Orderly  connection  release,  and 
Disorderly  connection  release. 

3.1.2  Distributed  Single-Layer  Embedded  ACSE  Testing  for  FTAM 
Initiator 


3. 1.2.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  ACSE  initiators  may  be  conducted  in 
conjunction  with  FTAM,  presentation  and  ASN.l  over  a tested  GOSIP 
session  platform,  or  else  in  conjunction  with  FTAM,  presentation, 
ASN.l  and  session  over  a tested  GOSIP  transport  platform.  Test 
coordination  is  by  agreed  procedures  between  test  laboratory  and 
product  supplier.  This  uses  the  distributed  single-layer  embedded 
method  of  testing.  All  Tested  Transport  Platforms  (TTPs)  are 
applicable. 

Applicable  profiles  are: 

FTAM/ACSE/Presentation/Session/TTPs . 


3. 1.2. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 
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1)  Capability  to  construct  APDUs  and  send  them  to  a peer  ACSE 
entity  under  test  over  a presentation-layer  service. 

2)  Capability  to  receive  and  decode  APDUs  and  classify  them 
according  to  IS  8650.  Capability  to  validate  APDUs  received  and 
record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  APDUs. 

4)  Capability  to  monitor  and  initiate  APDU  exchanges  with  the  SUT 
(inopportune  as  well  as  normal)  and  to  record  the  results. 

5)  Capability  to  control  and  to  coordinate  with  the  SUT  in  order 
to  induce  the  SUT  to  generate  specified  types  of  APDU.  This 
control  and  coordination  of  an  embedded  association  control 
entity  is  effected  by  manipulation  of  higher  layer  PDUs  which 
drive  the  association  control  service. 

3. 1.2. 3 Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  general 
behaviors  of  the  ACSE  lUT. 

Negotiate  and  support  throughout  the  connection  the 
functional  units  and  options  of  ACSE  which  are  identified 
within  the  GOSIP  and  the  Stable  Implementation  Agreements 
[NIST  2,  NIST  9]. 

Respond  correctly  to  improperly  negotiated  options. 

- Respond  correctly  to  options  negotiated  properly  but  violated 
during  subsequent  conduct  of  the  connection. 

Recovery  from  inopportune  APDUs  in  all  states. 

Recovery  from  invalid  APDUs,  where  specified. 

Recovery  from  different  uses  of  the  underlying  presentation 
connection. 

Specific  functions  for  which  tests  shall  exist  include: 

- Accept  a valid  AARQ  APDU  and  responding  with  an  AARE  APDU; 

- Association  release  and  abort  tests; 

Transparent  use  of  required  presentation  and  session  services 
including: 

Normal  data  transfer,  and  duplex. 

Minor  synchronization  point. 

Resynchronize , 

Orderly  connection  release,  and 
Disorderly  connection  release. 


3.2  FTAM 

3.2.1  Remote  Single-Layer  FTAM  Responder  Testing 
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3. 2. 1.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  FTAM  responders  may  be  conducted  in 
conjunction  with  ACSE,  presentation  and  ASN.l  over  a tested  GOSIP 
session  platform,  or  else  in  conjunction  with  ACSE,  presentation, 
ASN.l  and  session  over  a tested  GOSIP  transport  platform.  Test 
coordination  is  implicit,  since  the  only  point  of  control  and 
observation  is  remotely  over  the  transport  (or  session)  service. 
This  uses  the  remote  single  layer  method  of  testing.  All  Tested 
Transport  Platforms  (TTPs)  are  applicable. 

Applicable  profiles  are: 

FTAM/ACSE/Presentation/Session/TTPs . 

3 .2. 1.2  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  FPDUs  according  to  ISO  IS  8571,  using 
ASN.l  in  conjunction  with  ACSE  PDUs,  and  send  them  to  a peer 
FTAM  entity  under  test  over  a presentation-layer  service. 

2)  Capability  to  receive  and  decode  FPDUs  encoded  using  ASN.l. 
Capability  to  reconcile  received  FPDUs  with  those  previously 
sent  and  record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  FPDUs. 

4)  Capability  to  monitor  and  initiate  FPDU  exchanges  with  the  SUT 

(inopportune  as  well  as  normal)  and  to  record  the  results. 

5)  Capability  to  control  and  to  coordinate  with  the  SUT  in  order 

to  induce  the  SUT  to  generate  specified  types  of  FPDU. 

6)  Capability  to  negotiate  and  encode  specified  document  types. 

7)  Capability  to  decode  document  types  according  to  ISO  IS  8571. 

8)  Capability  to  negotiate  and  enforce  specified  implementation 
profiles. 


3. 2. 1.3  Test  Suite  Coverage 

The  Test  Suite  shall  contain  tests  for  the  following  general 
behaviors  of  the  FTAM  responder. 

Negotiation  and  support  throughout  the  association  of  the 
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document  types  and  implementation  profiles  which  are 
identified  within  the  GOSIP  and  the  Stable  Implementation 
Agreements  [NIST  9]. 

- Response  to  inopportune  FPDUs. 

Response  to  invalid  FPDUs,  where  specified. 

Response  to  valid  and  invalid  Grouping  sequences. 

Response  to  different  uses  by  the  means  of  testing  of  the 
associated  ACSE  unit. 

- Response  to  different  uses  of  the  underlying  presentation 
connection. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

FTAM  Regime  establishment,  including: 

response  to  a valid  F_initiate_Request  specifying  a 
statically  agreed  service  class, 

initiation  of  a valid  F_Initialize_Response  confirming  the 
same  service  class,  or  lesser  functionality; 

FTAM  regime  termination  (orderly) ; 

File  selection; 

File  deselection; 

File  open; 

File  close; 

Locate ; 

- Erase; 

File  creation; 

File  deletion; 

Read  attributes; 

Change  attributes ; 

Begin  group; 

End  group ; 

FTAM  regime  termination  (abrupt) ; 

Treatment  of  protocol  errors. 

Document  types  for  which  tests  shall  exists  include  the  following: 

- FTAM-1. 

- FTAM- 2 ; 

- FTAM- 3 ; 

- NBS-6; 

- NBS-7 ; 

- NBS-8 ; 

- NBS-9. 

Implementation  profiles  for  which  tests  shall  exist  include  the 
following: 


- Tl: 

simple  file  transfer; 

- T2: 

positional  file  transfer; 

- T3: 

full  file  transfer; 

- Al: 

simple  file  access; 

- A2: 

full  file  access; 

- Ml: 

management . 
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3.2.2  Distributed  Single-Layer  FTAM  Initiator  Testing 

3. 2. 2.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  FTAM  initiators  may  be  conducted  in 
conjunction  with  ACSE,  presentation  and  ASN.l  over  a tested  GOSIP 
session  platform,  or  else  in  conjunction  with  ACSE,  presentation, 
ASN.l  and  session  over  a tested  GOSIP  transport  platform.  Test 
coordination  is  by  agreed  procedures  between  test  laboratory  and 
product  supplier.  This  uses  the  distributed  single  layer  method  of 
testing.  All  Tested  Transport  Platforms  (TTPs)  are  applicable. 
Applicable  profiles  are: 

FTAM/ACSE/Presentation/Session/TTPs . 

3. 2 .2. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  FPDUs  according  to  ISO  IS  8571,  using 
ASN.l  in  conjunction  with  ACSE  PDUs,  and  send  them  to  a peer 
FTAM  entity  under  test,  in  response  to  FPDUs  initiated  by  the 
SUT,  over  a presentation-layer  service. 

2)  Capability  to  validate  received  FPDUs  and  record  the  results. 

3)  Capability  to  construct  invalid  as  well  as  valid  FPDUs. 

4)  Capability  to  monitor  (inopportune  as  well  as  normal)  FPDU 
exchanges  with  the  SUT  and  to  record  the  results. 

5)  Capability  to  control  and  to  coordinate  with  the  SUT  in  order 
to  induce  the  SUT  to  generate  specified  types  of  FPDU.  This 
includes  control  and  coordination  using  specified  test 
coordination  procedures. 

6)  Capability  to  negotiate  and  encode  specified  document  types. 

7)  Capability  to  decode  document  types  according  to  ISO  IS  8571. 

8)  Capability  to  negotiate  and  enforce  specified  implementation 
profiles. 

3. 2. 2. 3 Test  Suite  Coverage 

The  Test  Suite  shall  contain  tests  for  the  following  behaviors  of  the 
FTAM  Initiator. 

Negotiation  and  support  throughout  the  association  of  the 
document  types  and  implementation  profiles  which  identified 
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are  within  GOSIP  and  the  Stable  Implementation  Agreements 
[NIST  9] . 

Response  to  inopportune  FPDUs. 

Response  to  invalid  FPDUs,  where  specified. 

Response  to  valid  and  invalid  Grouping  sequences. 

Response  to  different  uses  by  the  means  of  testing  of  the 
associated  ACSE  unit. 

Response  to  different  uses  of  the  underlying  presentation 
connection. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

- FTAM  Regime  establishment,  including: 

Initiation  of  a valid  F_initiate_Request  specifying  a 
statically  agreed  service  class, 

acceptance  of  a valid  F_Initialize_Response  confirming  the 
same  service  class,  or  lesser  functionality; 

FTAM  regime  termination  (orderly) ; 

File  selection; 

File  deselection; 

File  open; 

File  close; 

Locate ; 

Erase ; 

File  creation; 

File  deletion; 

Read  attributes; 

Change  attributes; 

- Begin  group; 

End  group ; 

FTAM  regime  termination  (abrupt) ; 

Treatment  of  protocol  errors. 

Document  types  for  which  tests  shall  exists  include  the  following: 

- FTAM-1; 

- FTAM-2 ; 

- FTAM- 3 ; 

- NBS-6; 

- NBS-7; 

- NBS-8 ; 

- NBS-9. 

Implementation  profiles  for  which  tests  shall  exist  include  the 
following: 


- Tl: 

simple  file  transfer; 

- T2: 

positional  file  transfer; 

- T3: 

full  file  transfer; 

- Al: 

simple  file  access; 

- A2 : 

full  file  access; 

- Ml: 

management . 
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3.3  X.400  Message  Handling  Service 

Applicable  profiles  are  as  follows: 

P2/Pl/RTS/Session/TTPs 

3.3.1  Distributed  Single-layer  Embedded  RTS  Testing 

3. 3. 1.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  the  Reliable  Transfer  Service  is  conducted  in 
conjunction  with  the  Interpersonal  Message  Service  (IPMS,  or  P2)  , and 
the  Message  Transfer  Service  (PI)  over  a tested  transport  platform 
using  the  distributed  single-layer  embedded  method  of  testing.  Test 
coordination  is  by  agreed  procedures  between  test  laboratory  and 
product  supplier.  These  are  the  End  System  configurations.  The 
requirement  for  testing  the  Reliable  Transfer  Service  (RTS)  within  a 
Message  Transfer  Agent  (MTA)  relay  is  for  Basic  Interconnection  Tests 
only. 


3. 3. 1.2  Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 

shall  support  the  following  functions  in  addition  to  the  general 

functions  given  in  clause  2.1  above. 

1)  The  capability  to  initiate  RTS  ASPs  according  to  CCITT  X.410  and 
send  them  over  a session-layer  service. 

2)  Capability  to  interpret  received  RTS  ASPs  and  record  the 
results. 

3)  Capability  to  initiate  all  primitives  specified  in  X.410,  with 
valid  or  invalid  parameter  values. 

4)  Capability  to  control  and  coordinate  with  the  SUT  in  order  to 
induce  the  SUT  to  generate  specified  types  of  RTS  ASP.  This 
includes  control  and  coordination  using  specified  test 
coordination  procedures. 

3. 3. 1.3  Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  general 

behaviors  of  an  RTS  entity. 

Negotiation  and  support  throughout  the  association  of  all  RTS 
options  within  the  Stable  Implementation  Agreements  [NIST  2, 
NIST  9] . 

Exercising  of  all  RTS  abstract  services  specified  in  CCITT 
X.410. 
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RTS  encoding  strategies  not  covered  by  session. 

Response  to  ASPs  with  invalid  combinations  of  functional 
units. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

lUT  accepts  an  association  initiated  by  the  means  of  testing 
with  a valid  Pconnect  element;  acceptance  is  signified  by 
sending  an  Open__response  primitive  carrying  a valid  Pacceot 
element; 

lUT  initiates  an  association  using  Open_request  with  a valid 
Pconnect  element,  and  accepts  the  means  of  testings  response 
of  Open_response  carrying  a Pacceot  element; 

Invalid  association  establishment  attempt; 

Data  transfer; 

Association  termination; 

Multiple  (i.e.,  more  than  one)  concurrent  associations 
established; 

- Multiple  consecutive  session  connection  establishment  using 
one  RTS  association. 

3.3.2  Distributed  Single-layer  Embedded  PI  Testing 

3. 3. 2.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  the  PI  message  transfer  service  is  conducted 
in  conjunction  with  IPMS  (P2)  over  a tested  transport  platform  using 
the  distributed  single-layer  embedded  method  of  testing. 

3. 3. 2. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  PI  PDUs  according  to  CCITT  X.411,  using 
ASN.l,  in  conjunction  with  P2  PDUs,  and  send  them  to  a peer 
message  transfer  agent  entity  over  RTS. 

2)  Capability  to  decode  and  validate  received  PI  PDUs  and  record 
the  results. 

3)  Capability  to  construct  PI  PDUs  with  invalid  structure  or 
invalid  parameter  encodings. 

4)  Capability  to  monitor  and  initiate  exchanges  of  PI  PDUs  with  the 
SUT  and  record  the  results. 

5)  Capability  to  control  and  coordinate  with  the  SUT  in  order  to 
induce  the  SUT  to  generate  specified  types  of  PI  PDU.  This 
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includes  control  and  coordination  using  specified  test 
coordination  procedures. 

6)  Capability  to  operate  the  underlying  reliable  transfer  service, 
normally  or  abnormally. 

3. 3.2 .3  Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  behaviors  of  the 
message  transfer  agent. 

- Support  of  the  PI  protocol  elements  defined  in  the  Stable 
Implementation  Agreements  [NIST  , NIST  92]; 

Response  to  means  of  testing  attempts  to  include  unsupported 
elements  in  PI; 

Response  to  PI  PDUs  carrying  invalid  parameter  encodings  and 
invalid  values; 

Response  to  tester *s  abnormal  operation  of  the  underlying 
RTS. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

Initiation  and  acceptance  of  user  MPDU,  delivery  report  MPDU, 
and  probe  MPDU; 

Support  of  the  following  functions  by  Initiator  or  receiver: 
Content  Type  Indication, 

Converted  Indication, 

Delivery  Time  Stamp  Indication, 

Message  Identification, 

Non-delivery  Notification, 

Original  Encoded  Information  Types  Indication, 

Submission  Time  Stamp  Indication, 

Alternate  Recipient  Allowed, 

Conversion  Prohibition, 

Delivery  Notification, 

Explicit  Conversion, 

Grade  of  Delivery  Selection, 

Multi-destination  Delivery; 

Error  handling  test  for  the  following  actions: 

Invalid  context  specific  tag  in  an  MPDU, 

Pragmatic  Constraints  violations. 

Protocol  violations  (such  as  insufficient  number  of 
protocol  elements  present,  or  protocol  elements  of  invalid 
type  are  present) , 

ORNames  with  one  invalid  element  (in  different  elements) ; 
Tests  for  message  transfer  protocol  elements  marked  ‘non- 
support* in  the  Stable  Implementation  Agreements  [NIST  2, 
NIST  9] ; 

Deferred  Delivery, 

PerDomainBilaterallnf o , 

Explicit  Conversion, 

Alternate  Recipient  Allowed, 
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Content  Return  Request; 

Tests  for  message  transfer  protocol  elements  marked  'not 
used*  in  the  Stable  Implementation  Agreements  [NIST  2,  NIST 
9]; 

Tests  for  invalid  ASN.l  encoding  of  PI  PDUs. 

3.3.3  Distributed  Single-Layer  P2  Testing 

3. 3. 3.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  the  P2  interpersonal  messaging  service  is 
conducted  in  conjunction  with  PI  over  a tested  transport  platform 
using  the  distributed  single-layer  method. 

3. 3. 3. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met,  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
function  given  in  clause  2.1  above. 

1)  Capability  to  construct  P2  PDUs  according  to  CCITT  X.420,  using 
ASN.l  basic  encoding  rules,  and  send  them  to  a peer 
interpersonal  messaging  entity  over  a message  transfer  service. 

2)  Capability  to  decode  and  validate  received  P2  PDUs  and  record 
the  results. 

3)  Capability  to  construct  P2  PDUs  with  invalid  structure  and 
invalid  parameter  encodings. 

4)  Capability  to  monitor  and  initiate  exchanges  of  P2  PDUs  with  the 
SUT  and  record  the  results. 

5)  Capability  to  control  and  coordinate  with  the  SUT  to  induce  the 
SUT  to  generate  specified  types  of  P2  PDUs.  This  includes 
control  and  coordination  using  specified  test  coordination 
procedures . 

6)  Capability  to  operate  the  underlying  message  transfer  service, 
normally  or  abnormally. 

3. 3. 3. 3 Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  behaviors  of  the 
Interpersonal  Messaging  User  Agent. 

Support  of  the  P2  protocol  elements  defined  in  the  Stable 
Implementation  Agreements  [NIST  2,  NIST  9]. 

Response  to  means  of  testing  attempts  to  include  unsupported 
elements  in  P2 . 

Response  to  Inopportune  P2  PDUs. 

- Response  to  P2  PDUs  carrying  invalid  parameter  encodings  and 
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invalid  values. 

- Response  to  tester *s  abnormal  operation  of  the  underlying 
Message  Transfer  Service. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 

Initiation  and  acceptance  of: 

User  Message  UAPDU,  and 
Status  Report  UAPDU; 

Support  of  the  following  functions  by  initiator: 

Content  Type  Indication, 

Message  Identification, 

Non-delivery  Notification, 

Original  Encoded  Information  Types  Indication, 

Submission  Time  Stamp  Indication, 

IP-Message  Identification, 

Typed  Body, 

Conversion  Prohibition, 

Delivery  Notification, 

Grade  of  Delivery  Selection, 

Multi  Destination  Delivery, 

Originator  Indication, 

Primary  and  Copy  Recipients  Indication, 

Replying  IP  Message  Indication,  and 
Subject  Indication; 

Support  of  the  following  functions  by  receiver : Content  Type 
Indication, 

Converted  Indication, 

Delivery  Time  Stamp  Indication, 

Message  Identification, 

Original  Encoded  Information  Types  Indication, 

Submission  Time  Stamp  Indication, 

IP-Message  Identification, 

Typed  Body, 

Authorizing  Users  Indication, 

Auto  Forwarded  Indication, 

Blind  Copy  Recipient  Indication, 

Body  Part  Encryption  Indication, 

Conversion  Prohibition, 

Cross  Referencing  Indication, 

Disclosure  of  Other  Recipients, 

Expiry  Date  Indication, 

Forwarded  IP-Message  Indication, 

Grade  of  Delivery  Selection, 

Importance  Indication, 

Multi  Part  Body, 

Obsoleting  Indication, 

Originator  Indication, 

Primary  and  Copy  Recipients  Indication, 

Reply  Request  Indication, 

Replying  IP-Message  Indication, 

Sensitivity  Indication,  and 
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Subject  Indication; 

Test  for  invalid  ASN.l  encoding  of  P2  PDUs. 

3.3.4  PI  Relay  Testing 

3. 3 -4.1  Configuration  of  the  Means  of  Testing 

Conformance  testing  of  a PI  relay  entity  is  conducted  by  placing  the 
relay  between  two  MTA  End  Systems  and  operating  over  contiguous  RTS 
associations  using  the  Transverse  testing  method. 

3. 3. 4. 2 Characteristics  of  the  Means  of  Testing 

For  dynamic  conformance  conditions  to  be  met  the  means  of  testing 
shall  support  the  following  functions  in  addition  to  the  general 
functions  given  in  clause  2.1  above. 

1)  Capability  to  construct  PI  PDUs  according  to  CCITT  X.411,  using 
ASN.l,  in  conjunction  with  P2  PDUs,  and  send  them  to  a peer 
Message  Transfer  Agent  End  System  through  a relaying  MTA  which 
is  the  system  under  test. 

2)  Capability  to  decode  and  validate  received  PI  PDUs  and  record 
the  results. 

3)  Capability  to  construct  PI  PDUs  with  invalid  structure  or 
invalid  parameter  encodings. 

4)  Capability  to  monitor  and  initiate  exchanges  of  PI  PDUs  with  the 
SUT  and  record  the  results. 

5)  Capability  to  operate  the  underlying  reliable  transfer  service, 
normally  or  abnormally. 

3. 3. 4. 3 Test  Suite  Coverage 

The  test  suite  shall  contain  tests  for  the  following  behaviors  of  the 
Message  Transfer  Agent  relay. 

Support  of  the  PI  protocol  elements  defined  in  the  Stable 
Implementation  Agreements  [NIST  2,  NIST  9]. 

Response  to  means  of  testing  attempts  to  include  unsupported 
elements  in  PI. 

Response  to  inopportune  PI  PDUs. 

- Response  to  PI  PDUs  carrying  invalid  parameter  encodings  and 
invalid  values. 

Response  to  tester's  abnormal  operation  of  the  underlying 
RTS. 

Specific  functions  for  which  tests  shall  exist  include  the  following: 
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Acceptance  and  forwarding  of: 

UserMPDU, 

DeliveryReportMPDU,  and 
ProbeMPDU ; 

Support  of  the  following  functions: 

Content  Type  Indication, 

Converted  Indication, 

Delivery  Time  Stamp  Indication, 

Message  Identification, 

Non-delivery  Notification, 

Original  Encoded  Information  Types  Indication, 

Submission  Time  Stamp  Indication, 

Alternate  Recipient  Allowed, 

Conversion  Prohibition, 

Delivery  Notification, 

Explicit  Conversion, 

Grade  of  Delivery  Selection;  and 
Multi-destination  Delivery. 

Error  handling  test  for  the  following  actions: 

Invalid  context  specific  tag  in  an  MPDU 
Pragmatic  Constraints  violations 

Protocol  violations  (such  as  insufficient  number  of 
protocol  elements  present,  and  protocol  elements  of 
invalid  type  are  present) , and 
ORNames  with  one  invalid  element  (in  different  elements) ; 

Tests  for  message  transfer  protocol  elements  marked  ‘non- 
support* in  the  Stable  Implementation  Agreements  [NIST  2, 
NIST  9] . 

Deferred  Delivery, 

PerDomainBilaterallnfo, 

Explicit  Conversion, 

Alternate  Recipient  Allowed,  and 
Content  Return  Request; 

Tests  for  invalid  ASN.l  encoding  of  PI  PDUs; 

Trace  information  tests. 
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